Day 10

Keeping in sync

Commands in Play

  • git pull -> Sync local repo with an upstream repo. It is really two commands: git fetch and git merge
  • git fetch -> The first part of git pull
  • git merge FETCH_HEAD -> Merge new commits from FETCH_HEAD into the current branch
  • git pull —ff-only -> Merge only if FETCH_HEAD is a descendant of the current branch (a fast-forward merge)
  • git branch —set-upstream-to=origin/main -> This would be a reset to your local branch to be based from its origin clone (but you can imagine that you may go elsewhere at an as-needed basis)

It’s all about git pull, which is compromised by two commands: git fetch and git merge

A snapshot looking at the math.git repo at owner 'Carol'. Another dev has pushed a change to math.git so that Carol's local is out of date.
A snapshot looking at the math.git repo at owner ‘Carol’. Another dev has pushed a change to math.git so that Carol’s local is out of date.
  • The merge is the more substantial operation. It’s much more complicated than git push. When changes can be cleanly merged, git pull is just the mirror operation of git push. Anything more complicated, and you have to make the merge in a local repository and then push the result.
  • Consider this sentence from the git pull help page: “In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.”
    • So git fetch retrieves references, this means branches or tags.
    • When the references arrive at the local repo, they are laid down on top of it, along with any files that they point to.
    • These references are tracked by using remote-tracking branches.
A snapshot looking at the math.git repo at owner 'Carol'. The command flag `--decorate` provides a list of the SHA1 IDs and the **references** (shown in parentheses, like this 😉). Remote references are prepended with `origin/`. The label HEAD is your git playback machine, and it is always pointing to your current branch.
A snapshot looking at the math.git repo at owner ‘Carol’. The command flag --decorate provides a list of the SHA1 IDs and the references (shown in parentheses, like this 😉). Remote references are prepended with origin/. The label HEAD is your git playback machine, and it is always pointing to your current branch.

NB. The state of Carol’s repo ☝️ is after the git pull from the main branch math.git. See how the SHA1 ID 080a405 is now the HEAD and it has a reference to origin/. This was a “clean merge” of the repos and the complexity was wrapped by that git pull.

The View definition in gui app ‘gitk’ allows you to show all local and remote branches.
The View definition in gui app ‘gitk’ allows you to show all local and remote branches.
App GITK showing the history, with labels for the remote tracking branches on top.
App GITK showing the history, with labels for the remote tracking branches on top.

git fetch > git pull

In the terminal from Carol's repo, we done a `git fetch`. The remote-tracking branch (SHA1 ID: 6fead5c) is ahead of the local HEAD (SHA1 ID: 08a405).
In the terminal from Carol’s repo, we done a git fetch. The remote-tracking branch (SHA1 ID: 6fead5c) is ahead of the local HEAD (SHA1 ID: 08a405).

So to consider the actions of git pull at a step-wise basis, access the remote master branch in Carol’s repo via: git rev-parse origin.main.

  • ☝️ That latter command will give you the same SHA1 ID as FETCH_HEAD!

You still have two commit IDs, see what is different between these two branches by entering: git diff HEAD..FETCH_HEAD.

  • FETCH_HEAD is used as the argument to git merge.
  • FETCH_HEAD is the reference to the remote branch that was previously fetched.
Performing a git merge on the CLI opens up the default editor for the commit message. Note the comment that an empty message aborts the commit!
Performing a git merge on the CLI opens up the default editor for the commit message. Note the comment that an empty message aborts the commit!
  • ☝️ Performing the git merge results in a Fast-Forward to the local branch!
Previous
Next