What does `git fetch origin master:master` mean?

Question

What does git fetch origin master:master mean?

I mean the master:master part: I know what git fetch origin means, but what about the master:master part?

Answer 1

git fetch origin master:master and it's more recent twin git fetch origin main:main behave VERY much like git pull. They first fetch, and then do a fast-forward merge so that the local main will match what was fetched from origin.

There is one exception: If it is necessary to do a new merge commit, git fetch origin main:main will NOT create that commit. If you add a + in front, that is, like git fetch origin +main:main, it will then "force" the remote branch to local, that is, forcing any local commits to main to be completely lost.

This is the mirror-image process of pushing: When you push, you can push new commits to origin unless someone else has already pushed to origin before you. But if they have, the push will fail. Likewise, git fetch origin main:main will pull from origin into your local main branch unless you have already committed to main locally. In both cases, you will need to do a local merge if the command fails.

I do NOT recommend using --force or + (either when pushing or fetching) until you have very significant experience with Git, know exactly what you are doing, and know what work you might lose and how it may impact others who are working with you.

---

From the docs for git fetch: [square-brackets indicate my commentary]

Whether that update is allowed without [+ or ] --force depends on the ref namespace it’s being fetched to, the type of object being fetched, and whether the update is considered to be a fast-forward. Generally, the same rules apply for fetching as when pushing, see the <refspec>... section of git-push[1] for what those are. Exceptions to those rules particular to git fetch are noted below. [emphasis added]

That is, when you fetch to a local branch, the update is allowed as long as it just extends the history, just like you can push a branch to the remote server as long as it extends that branch's history on the server. In both cases, if the branch has already been extended since the last update the fetch/push will fail unless it is forced.

As with pushing with git-push[1], all of the rules described above about what’s not allowed as an update can be overridden by adding an optional leading + to a refspec (or using the --force command line option). The only exception to this is that no amount of forcing will make the refs/heads/* namespace accept a non-commit object.

Using refspecs explicitly:

$ git fetch origin +seen:seen maint:tmp

This updates (or creates, as necessary) branches seen and tmp in the local repository by fetching from the branches (respectively) seen and maint from the remote repository.

The seen branch will be updated [force-pulled] even if it does not fast-forward, because it is prefixed with a plus sign; tmp will not be.

Answer 2

The arguments after the remote (origin) are refspecs.

Using master:master will overwrite your master branch; see this answer.

See this answer for even more about git fetch's behavior with and without refspec arguments.