Git Repositories#

In this course, we use Git and GitLab for version control and for submitting assignment code. Git is for managing repositories of code, which are essentially collections of files managed together. GitLab is for managing projects, and each project has a repository, hosted on the GitLab server.

Everyone working with a repository has their own full copy of it, and Git is used to synchronize the copies at various points in time.

One-time (per computer) initial configuration options#

When we use Git on a new computer for the first time, we need to set up a few one-time initial configuration options. The very minimal one-time options to be set up to start using Git are: our name, our email address, and our preferred command-line text editor. This is achieved by means of the following three Git commands, respectively:

git config --global user.name "Given name(s) Family name"
git config --global user.email "uid@anu.edu.au"
git config --global core.editor "nano"

where you have to replace "Given name(s) Family name" by your own names, and "uid@anu.edu.au" by your actual ANU e-mail address. The values provided to the user.name and user.email options are used by Git in order to identify the changes that you perform on the repository files by your name and e-mail address. Indeed, as we will see below, each time that you save a set of changes, i.e., each time that you create a new “commit”, your name and e-mail address will be associated to these changes. On the other hand, the value provided to the core.editor option tells Git which command-line editor to be used. In particular, the editor is called by Git whenever it requires that you associate a message to a newly created commit. In the command above, we are telling Git to use the GNU nano editor, although you can also use others such as, e.g., vim. Finally, it is important to mention that the three commands we just ran only need to be run once: the flag --global tells Git to use the settings for every project, in your user account, on this computer. You can change your configuration as many times as you want: use the same commands to choose another editor or update your email address.

Cloning#

If there already exists a project on GitLab that you would like to get a local copy of, use the git clone command, as in:

git clone [address-of-your-repository]

This creates a new folder wherever you currently are in your terminal, which contains the files of the repository.

In general, the address of your repository will look as follows:

git clone https://gitlab.cecs.anu.edu.au/u1234567/comp1110-2025s1-u1

(adjusted for your relevant assignment and course code).

DO NOT clone the template repositories (whose address has comp1110/2025s1/ instead of your uid in the middle). You need to create your own fork of the template repository on GitLab (use the fork button on the top right).

Pulling#

If you have already cloned a repository, to update it from the server, go into the folder of the repository (the one created by git clone), and run

git pull

In this course, this is only necessary if you work on multiple computers - you can push your work to the server and then pull it on another computer.

Make sure to never work on two computers without pushing to the server and pulling from it on the other computer when changing from one computer to the other. Git is technically supposed to support messing this up, but it gets complicated quickly, and while you will eventually learn to do this elsewhere, we do not use this functionality in this course!

Committing#

Git actually keeps two things on your computer for every repository that you copy to it:

  • the current files of the repository that you are working on
  • a complete history of checkpoints, so-called commits

You can create a checkpoint whenever you want to. To do this, first run

git status

This will show you a list of all the files that have changed since the last commit. This includes files that you have newly added, deleted, or just edited.

For files that you have edited, you can write

git diff [path-to-file]

To show the changes you have made since the last commit.

Next, you have to select which changes (on the granularity of files) you want to include in the commit. This is called staging. Run

git add [path-to-file]

to stage a file, meaning that it will be included in the next commit.

You can run

git status

again to check the new state - it will show you which files have been staged, and which are still unchanged but contain new changes.

Once you have selected all the files you want to include, run

git commit -m "[include an informative message here]"

You are required to use meaningful commit messages, for example:

  • “Fixed bug in calculating birthday”
  • “Added implementation of rocket launch” Depending on what it was you did in the actual commit. If you did lots of things, your commit message should be bigger. It is good practice to use smaller commits and commit more often.

While commit sounds a lot like commitment, it is in some ways the opposite. A commit gives you a point in time that you can always go back to (or, once you went further back, forward to), even if you committed things many more times. This means you can try out stuff, and if it doesn’t work, so long as you made a commit before, you can go back to how things were.

Note: a commit only changes the local history of your repository. To sync with the server, you need to push your commits to there.

Pushing#

Once your changes are committed, they can be pushed to the server, thereby synchronizing the repository there with yours. Once this is done, you can pull these changes onto another machine, too!

To push your changes, just run

git push

In this course, we require that you commit and push frequently. More on this in the section on Notebooks.

More Details on Git#

Check out the lecture on Git in MIT’s missing semester course.

Additional Git/GitLab instructions for exams#

For exams, all Git commands discussed above apply verbatim.

However, in contrast to assignments, for which you have the option to select which particular commit in your repository you want us to code walk (using CWAC), in the case of the exams (i.e., mid-sem test and final exam) we will be (auto-)marking the latest commit pushed to the remote repository.

If you have committed/pushed partial work that you were not able to finish during the exam, and that you do not want us to (auto-)mark, it is possible to retrieve your files in the status corresponding to a previous commit. Below we offer two alternatives to do this, with the first alternative being the preferred one.

The instructions below are dangerous, in the sense that you may loose work if you do not properly understand what you are doing. Generally, they won’t be needed during an exam. If you have doubts when using the instructions below, do not hesitate to ask to the examiners or invigilators.

Alternative 1#

Go to the main page of your repository in Gitlab. Then, click on the “History” button, shown in the screenshot below:

Click on your main repo page History button

This will lead to a list of previous commits pushed to the repository. Identify the commit you are interested in in the list, and then click on the “browse files” button corresponding to that commit, shown in the screenshot below:

Click on the browse files button corresponding to the commit you are interested in

This will lead to the main page of the particular commit of your interest. In such page, you can navigate through the files of the repository in the status corresponding to that commit. Locate the file of interest, and click on it. As a result you will open the page corresponding to the file. In that page, click on the Download button, show in the screenshot below:

Click on the download button corresponding to the file you are interested in

This will automatically trigger the download of the file, most probably on the Downloads folder of your home directory. The last steps are to (1) replace the downloaded file by the one currently available in your local clone of the repository; (2) commit; (3) push. Note that in step (1) you may loose work, so if you have doubts, before proceeding with (1) please ask to the examiners or invigilators.

Alternative 2#

Git provides functionality to change the latest commit so that it points to a previous commit instead.

To this end, you first need to identify which commit ID in your commit history you would like to become the latest commit. Show the commit history with

git --no-pager log

and then identify the commit ID you are interested in (Note: commit IDs are unique 40-character hexadecimal codes, such as, e.g., c64b6b3159b4e5be11c6e8cd04ab2d3a0b2c237c).

Let us call from now on commit_id_identified the commit ID that you identified. You can execute the following command to change the latest commit to commit_id_identified

git reset --mixed commit_id_identified

This command will remove all commits beyond commit_id_identified from your commit history. However, with safety in mind, it also gathers the changes in such commits as unstaged changes in your local workspace. You can see this with

git status

and

git diff

If you want to discard these changes, you just type, e.g.,

git stash

If you want to keep part of these changes, you will have to manually edit the files so that you leave them in the status you want us to mark.

Finally, the last step is

git push -f origin

to reflect the change in the commit history of the remote repository.

If you struggle while applying these instructions, please do not hesitate to ask to the examiners or invigilators.

Notebooks#

When you work on an assignment, you need to keep a notebook of your work sessions. This notebook is in the YAML format, and it is important that you stick to the requirements of the format, which in particular means not leaving out required dashes and colons, and getting the indentation right. Our notebooks consist of two sections - a time-on-task summary and a session log.

Time-on-Task#

The time-on-task summary specifies the overall minutes you worked on each part of an assignment. Each part has an entry consisting of two fields:

  • task, which is a string that names a part of an assignment, for example, “Part 1”
  • time, which is a number describing the number of minutes you worked on this part in total so far Altogether, the time-on-task summary might look as follows:
time-on-task:
- task: "Part 1"
  time: 75
- task: "Part 2"
  time: 58
- task: "Part 3"
  time: 83
- task: "Part 4"
  time: 240

Note that it is important that for each task/time pair, both entry names have the same indentation, and the first is preceded by a “-“ at 0 indentation.

The Session Log#

The session log keeps track of all the times you worked on the assignment. It is a list of entries with three fields each:

  • start, which is a timestamp in ISO-format (e.g. 2025-02-19 15:30)
  • end, which is a timestamp in ISO-format
  • notes, which is a text field describing what you did in that session. Altogether, a session log might look as follows:
sessions:
- start: 2025-02-19 15:30
  end: 2025-02-19 16:30
  notes: "worked on part 1, only tests missing"
- start: 2025-02-20 10:20
  end: 2025-02-20 10:35
  notes: "finished tests for part 1"
- start: 2025-02-20 10:35
  end: 2025-02-20 11:33
  notes: "implemented everything for part 2"
- start: 2025-02-21 18:00
  end: 2025-02-21 18:30
  notes: "stuck on part 3, no progress :("
- start: 2025-02-22 14:00
  end: 2025-02-22 14:53
  notes: "finished part 3 after all"
- start: 2025-02-22 14:53
  end: 2025-02-22 15:40
  notes: "data design for part 4"
- start: 2025-02-25 18:24
  end: 2025-02-25 19:00
  notes: "implemented draw function"
- start: 2025-02-26 15:00
  end: 2025-02-26 15:30
  notes: "tried implementing step function, but found issue with data design. need to re-do."
- start: 2025-02-26 17:20
  end: 2025-02-26 18:20
  notes: "fixed data design and updated draw function"
- start: 2025-02-27 10:30
  end: 2025-02-27 11:37
  notes: "implemented step function"
- start: 2025-02-27 15:28
  notes: "implementing keyEvent"

Note that in the last entry, the entry does not have an end time yet. This is good practice for our CI support, which will automatically check your notebook whenever you push, which may be in the middle of a work session.

We generally require that you commit and push:

  • at least once per hour (checked as no pushes during work sessions may be more than 70 minutes apart)
  • at the end of every work session
  • at least once per major part of the assignment

The notebook needs to match the time of your actual pushes, which are recorded by the server.

Putting it all together#

The total times-on-task (in minutes) need to match the recorded session times (we have a tolerance of 10 minutes difference to allow for some rounding). Not correctly maintaining your notebooks is associated with severe form penalties in our rubric. A complete notebook.yml might look as follows:

time-on-task:
- task: "Part 1"
  time: 75
- task: "Part 2"
  time: 58
- task: "Part 3"
  time: 83
- task: "Part 4"
  time: 240
sessions:
- start: 2025-02-19 15:30
  end: 2025-02-19 16:30
  notes: "worked on part 1, only tests missing"
- start: 2025-02-20 10:20
  end: 2025-02-20 10:35
  notes: "finished tests for part 1"
- start: 2025-02-20 10:35
  end: 2025-02-20 11:33
  notes: "implemented everything for part 2"
- start: 2025-02-21 18:00
  end: 2025-02-21 18:30
  notes: "stuck on part 3, no progress :("
- start: 2025-02-22 14:00
  end: 2025-02-22 14:53
  notes: "finished part 3 after all"
- start: 2025-02-22 14:53
  end: 2025-02-22 15:40
  notes: "data design for part 4"
- start: 2025-02-25 18:24
  end: 2025-02-25 19:00
  notes: "implemented draw function"
- start: 2025-02-26 15:00
  end: 2025-02-26 15:30
  notes: "tried implementing step function, but found issue with data design. need to re-do."
- start: 2025-02-26 17:20
  end: 2025-02-26 18:20
  notes: "fixed data design and updated draw function"
- start: 2025-02-27 10:30
  end: 2025-02-27 11:37
  notes: "implemented step function"
- start: 2025-02-27 15:28
  notes: "implementing keyEvent"

Ensure that indentations, dashes, columns, and field names are correct!

The times listed above are given in Canberra time. If you work in a different timezone, you need to either translate your time to Canberra time, or explicitly add your timezone’s offset to UTC to the timestamps, as in 2025-02-26 18:30+10:00 . You only need to do this for timestamps not in Canberra’s time zone.

bars search caret-down plus minus arrow-right times