I suppose that the commit history would be the same for both if I didn't make any local commits?

CodePudding user response：

The answer is both yes and no.

Suppose you've cloned a copy of the Git repository for Git (e.g., https://github.com/git/git.git). You're on your own master or main (they both exist and always identify the same commit on GitHub now, or are meant to anyway) and have made no new commits, but Junio has added some that are now on GitHub, so you run:

git fetch origin

and then:

git merge

or:

git rebase

to merge with, or rebase on, origin/main or origin/master depending on which of these two you prefer. (That is, your upstream of your M is your origin/M, whether M is master or main.)

• By default, git merge will do a fast-forward operation with the upstream. This advances your branch to match up with the remote-tracking name.

• In all cases, git rebase will checkout the tip commit of the upstream and then "replay" (cherry-pick) the commits you've made, which are no commits at all, and then reset your branch name to point here. This advances your branch to match up with the remote-tracking name.

So here, the answer is yes.

But note the phrase by default above. Suppose you ran:

git config merge.ff false

or:

git config --global merge.ff false

at some point in the past. Then your git merge command won't use the default of fast-forwarding; instead, it will create a new merge commit. So now the two commands give different results.

(You did—correctly—note that git merge --squash won't fast-forward either, and thus will likely do something you don't want.)

If you configure merge.ff to only, a plain git merge will be equivalent to git merge --ff-only, i.e., will attempt the fast-forward operation, but if that is not possible, will fail outright. In this mode both git merge and git rebase do the same thing for this case, but git rebase does something when you do have your own commits (vs git merge --ff-only, which fails instead).