Where does 'git fetch' place itself?

Question

Let's say I'm working on license.txt in my local repository, and I modify it. Before I commit, Susan modifies and commits it to the remote repository.

If I do git fetch, what exactly happens to my updates? Where do the results go?

Answer 1

Nothing happens to your updates. git fetch, for lack of a better word, fetches commits from a remote repository and places them in the local copy of the object database. Since you are working on your own branch, there's no interaction between them, until you explicitly choose to have some interaction, e.g., by rebasing, cherry-picking, etc.

You can access the fetched commits by checking out their respective branches (e.g., origin/master).

Answer 2

git fetch does not change the state of the working tree. In fact, it doesn't require a working tree: git fetch can work in a bare repository (a repository which has no working tree).

Susan's commit produces a new object in her repository. That object is not known in your workspace, until you perform the fetch. At that point, that object becomes available in your space. Because that object is identified by its hash, which is a very large integer, it is almost certainly distinct from (does not clash with) any other object that you already have.

In addition to fetching the new commit, git fetch will also update the remote branch pointers. For instance, suppose that Susan's master branch and yours were identical prior to Susan's commit. After Susan's commit, her branch has a new commit which yours does not. When you do the git fetch, your local origin/master branch pointer gets updated to indicate that its head is now Susan's commit. However, your local master branch stays unchanged.

At this point you can run git checkout (with no arguments) and you will get a message like branch master is behind origin/master by 1 commit and can be fast-forwarded. This comes from comparing master and origin/master.

You can now integrate with Susan's change in several ways:

• git rebase: cherry pick of the changes which are only in your local master on top of the new changes in origin/master (thereby rewriting their history), and make the result the new HEAD on the local master). After this, master is strictly ahead of origin/master: it is the same as origin/master, plus your changes.
• git merge: keep your changes intact, and produce a new commit on master which collapses them and merges them. This commit has two parents: the previous commit on master (in this case Susan's commit) and the last commit in your series of local commits, in their original form. Again, master is now strictly ahead of origin/master.
• git reset --hard origin/master: in recognition of Susan's commit making all your work obsolete, you throw your work away and purely fast-forward your local master to Susan's change. Now master is identical to origin/master.

The first two actions are combined with git fetch using the git pull command. git pull performs either git fetch followed by git merge or it performs git fetch performed by git rebase. The behavior is configurable per branch, and there is a global option about which way newly created branches should be configured. You can override the behavior using git pull --rebase or git pull --merge.

Since your local change is not committed, you will be prevented from taking these integrating actions (rebasing or merging). Git wants you to convert your changes to a commit first. There is no interaction between the newly fetched objects, and you making a commit out of your local changes.

You do not have to take any action now. Thanks to git fetch, you are informed about upstream activities, without having to integrate with them immediately. You can, for instance, do git log origin/master to see what is new, and how it might impact your work. But you can set that aside and keep making new commits.