Your Git then renames the branch tips: instead of 'branch master', your Git calls it 'remote-tracking branch origin/master'.

In normal, standard setups, 4 their Git sends you all their branch tips and all the commits and other objects your Git needs to use those. Let's look exclusively at the git fetch case now. (When you are pushing, your Git sends the pairs, and this is where the symmetry between fetch and push is deliberately broken.) When you are git fetch-ing from origin, origin's Git sends your Git these name/ID pairs.

If we put older commits on the left and newer ones on the right, we get something like this: o pairs. There's also at least one commit-the first commit you (or whoever) made-that has no parent: it can't have had a parent, because it was the first commit. Most commits have just one parent, but merge commits have two (or more but we'll stick with two). This actually means a lot, but for simple usage purposes we can boil it down to this: each commit has an ID-the big ugly SHA-1 hashes like 7452b4b5786778d5d87f5c90a94fab8936502e20-and each commit records its parent commit ID(s), which, in effect, means each commit 'points back' to its parent(s). Git's commit graph is a Directed Acyclic Graph or DAG.

If you already know all this, feel free to skip forward. Let's start with the third item first, because it's actually quite fundamental. (in fact there is no such thing, because git pull bypasses the fetch refspecs when it runs git fetch for you). This is why git fetch origin master:master is interesting, and also answers the question: This is going to tie together the fetch and the not-quite-merge fast-forward.įourth (and perhaps the most complicated part), git fetch does something interesting using what Git calls refspecs. Third, you need to understand how Git manages your commit graph and branch labels. And, while git rebase just does a rebase, if you have no commits of your own, the effect is the same as a fast-forward. This is kind of a misnomer, because a fast-forward is not actually a merge at all. Second, git merge may do something called a fast-forward merge. The git fetch step is where your Git actually picks up new commits from origin, if there are any to pick up. Which one you get-merge vs rebase-depends on how you have configured your Git repository and branches. It 'means' (slightly roughly) git fetch & git $something, where $something is either merge or rebase. Tim Biegeleisen's method is the simplest method, and maybe the best, but not exactly the same as your current workflow, though perhaps your current workflow is not ideal anyway.įirst, git pull is itself just a shortcut. All 'perfect' solutions require something at least a little tricky, or Git's new (since version 2.5) git add-worktree feature.

Quick shortcut master