Use of Git & GitHub
All your work for this module will be managed using the Git version control system.
You should have already used the GitHub Classroom link in Minerva to claim a GitHub repository. You will do all of your work for this part of the module in clones of this repository.
These clones can exist temporarily in the cloud, in a GitHub Codespace. You also have the option of working in a more permanent local clone, on your own computer or a SoCS lab machine.
Git Commands Refresher
Here’s a reminder of some of the Git commands that you used last year. You will need to use these again throughout this module.
| Command | Purpose |
|---|---|
| add | Add changes or new files to staging area, prior to committing |
| commit | Commit staged changes to the project history |
| fetch | Retrieve changes you don’t yet have from remote repository |
| log | Display the history of commits |
| mv | Move or rename a file or directory |
| pull | Fetch changes, then merge them into the current branch |
| push | Transfer commits from this clone to remote repository |
| rm | Remove files (or directories, with -r option) |
| status | Display repository status (very useful!) |
If you are not already fluent in the use of basic Git commands, it is essential that you achieve fluency in Semester 1 of COMP2850.
Without this as a solid foundation, you will not be able to participate effectively in the group work in Semester 2.
See the bottom of this page for links to some helpful Git resources.
Git Workflow
If you follow the approach outlined below, you will be able to work freely in Codespaces, or directly on the SoCS lab machines, or on your own PC, switching between these environments as you wish. (See the instructions on cloning if you plan to work directly on lab machines or your own PC.)
If you work in multiple clones of the repository and don’t follow this approach, you may encounter merge conflicts, which can be tricky to resolve.
Starting a Work Session
It’s very important that the clone you are working in has all of the latest changes that you have made. To achieve this, use
git pull
You can also do this via the VS Code GUI, by clicking on the Sync Changes button.
If you are working in a newly-created Codespace, with a fresh clone of the repository, this step will not be needed.
Ending a Work Session
At the end of a session (e.g., at the end of one of your timetabled classes), remember to add and commit changes to the clone you are working in, then push them back to GitHub.
You can achieve this with the following commands, entered into a terminal window:
git add -A
git commit -m "Finished work for Week 1, Session 1"
git push origin main
Adjust the commit message accordingly. Try to make sure that these messages are brief but accurate summaries of the commits you have made.
Note also that the commands above will commit all changes, made anywhere in
the repository. To be more selective, omit the -A option from git add and
instead provide pathnames for the files or directories containing the changes
you wish to include.
Alternatively, you can perform these operations in VS Code:
-
Open the Source Control panel, e.g., by pressing
Ctrl+Shift+G. -
Use the
+button next to a changed file to add that change to Git’s staging area, or use the topmost+button to stage all changes. -
Type your commit message into the text field at the top of the Source Control panel, e.g., “Finished work for Week 1, Session 1”.
-
Click the Commit button.
-
Click the Sync Changes button to push the commit to GitHub.
It is crucial that you commit changes and push those commits back to GitHub at the end of any work session done in a Codespace.
You may lose work if you forget to do this!
Useful Git & GitHub Resources
- Git cheatsheet
- Free book: Pro Git (2nd ed.)
- LinkedIn Learning course: Git Essential Training