Chapter 8: Robots and remote clones

Keeping your local repo up to date

face Josiah Wang

Now, let’s say I have made a new commit to my remote repo on GitLab. Of course, your local copy does not know anything about the changes.

Remote vs local branches

Perhaps one day, you finally decided to check whether I have updated anything remotely. So you type git fetch to check this.

user@MACHINE:~/josiah-robot$ git fetch
remote: Enumerating objects: 43, done.
remote: Counting objects: 100% (43/43), done.
remote: Total 43 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (43/43), 10.51 KiB | 1.31 MiB/s, done.
From https://gitlab.doc.ic.ac.uk/jwang4/70053-robot
   75d1feb..849a23a  main     -> origin/main
user@MACHINE:~/josiah-robot$  git log --oneline -5
849a23a (origin/main, origin/HEAD) Pretend that this is a new update I made since you last checked.
75d1feb (HEAD -> main) Refactored robot to group its attributes like id, name, position and direction as a single dict representation. Refactored all relevant function implementations accordingly.
00dbd2d Abstracted rows and columns to be a single tuple representation.
1aecbb6 The program now generates a unique ID for each robot.
a12bc76 The program now generates multiple robots, each navigating to a different target cell.

You can see that your local copy now knows that I had an update. But also notice that the local main branch is still stuck at where it was. This is because git fetch only checks for updates, but it does not update your local working directory. So your local copy of the files is still the older version.

Remote vs local branches after git fetch

The solution is to use git merge after a git fetch to merge/fast-forward to synchronise your local branch to the remote branch. We have already discussed git merge back in Lesson 5.

An easier approach is actually to just use the git pull command, which basically does a git fetch followed by a git merge.

Remote vs local branches after git pull