In the following example, is there a way to know a merge happened? Looking at git log, I can\'t tell I merged.
# setup example directory
$ mkdir test
$ cd test
You can use git merge-base:
git merge-base master topic
It will show the cccc64de3947828f487a8ce3c3e72b0f68dc88c3
( 2) commit
Or you can use:
git show $(git merge-base master topic)
In that instance, git has spotted that it's possible to do a so-called "fast-forward" merge, since the branch you're merging in already contains everything in the current branch - it doesn't need to create a new commit in the commit graph to join the two branches.
If you don't like that behaviour, and want create a merge commit even when fast-forwarding is possible, you should merge in the other branch with:
git merge --no-ff topic
However, if you really need to know whether a merge happened or not, you can find that information in the "reflog". For example, in your situation, git reflog
would produce the following output:
1eecbcb HEAD@{0}: merge topic: Fast-forward
193ae5e HEAD@{1}: checkout: moving from topic to master
1eecbcb HEAD@{2}: commit: 2
193ae5e HEAD@{3}: checkout: moving from master to topic
193ae5e HEAD@{4}: commit (initial): 1
... which shows you how HEAD
was changed recently, and what action caused that to happen. However, relying on the reflog is generally a bad idea except in particular situations, such as recovering from errors - it's better to just think in terms of the commit graph, and make that represent what you've done. git merge --no-ff
is one such method that lots of people like.
If you would like to try a case where you have a real merge, you could run the following commands after git checkout master
:
touch c
git add c
git commit -m "3"
git merge topic
That is, you add a commit to the master branch. Then the graph of commits is no longer a linear sequence, and data has to be merged from multiple branches.