15

How come when I create a new branch and make commits to it I am not seeing it branch off in my graph.

Here is the code i am doing:

git init

git add .
git commit -a

... other commits in here

git checkout -b mynewbranch

git add .
git commit -a

git checkout master
git merge mynewbranch

git add .
git commit -a

This is what I expect to see in my mind when I perform git log --graph

* 47926e1 This is a commit back on master
 \
  * f3dc827 How come i am not seeing a branch in my tree
  * 1cd3018 This should be on my new branch  
 /
* 47f3716 This is my third commit
* 878b018 This is my second commit 
* 2db9f83 Initial commit

But I am seeing this:

* 47926e1 This is a commit back on master
* f3dc827 How come i am not seeing a branch in my tree
* 1cd3018 This should be on my new branch
* 47f3716 This is my third commit
* 878b018 This is my second commit
* 2db9f83 Initial commit

Am I not understanding something?

Bryan Anderson
  • 275
  • 2
  • 7
  • 3
    git is doing a fast forward on your branch since there are no other commits. try git merge --no-ff mynewbranch to record it as merge off that branch – Doon Apr 25 '13 at 14:29
  • Is that the best practice way or is that just to show aesthetically that they are separate branches? – Bryan Anderson Apr 25 '13 at 14:34
  • 1
    it is up to you, and how you want to tree to look. and if it is important to you to show that the work was done in that branch. If you do this a ton, your commit history is littered with branches, and can be hard to follow. The best practice is normally defined by the team you are working with and how they want to use git. – Doon Apr 25 '13 at 14:39
  • Fair enough. Thank you very much for the advice. – Bryan Anderson Apr 25 '13 at 14:42
  • that being said, I tend to avoid merges when possible unless recording the merge brings something extra, else I try to rebase the merges away.. – Doon Apr 25 '13 at 14:43
  • We are working in an Agile environment where we would like to break out each sprint as a branch and then merge it back to master. So I would like to see the history for changes made during each sprint – Bryan Anderson Apr 25 '13 at 14:47

1 Answers1

19

If there are no commits to master while you are working on mynewbranch, your history will look like what you've shown. In that case, no actual merge is required; merged master is identical to the tip of mynewbranch. If this is the case, git will (by default) do what is known as a fast-forward merge; master's branch pointer is just updated to be the same commit as the tip of your merge. This usually results in a simpler commit history that is easier to work with, especially if work is also going on in remote repositories.

If you want to force the merge to be recorded as a merge in git, you can use the --no-ff option on git merge.

In git, it's generally considered good practice to avoid merges where possible.

antlersoft
  • 14,636
  • 4
  • 35
  • 55
  • Thank you for that excellent explanation. My question is this, is it best practice to use the non-fast-forward option or to just let git decide? – Bryan Anderson Apr 25 '13 at 14:37
  • Regarding fast-foward vs non-fast-forward merge, I've seen people make arguments supporting both ([Git flow](http://nvie.com/posts/a-successful-git-branching-model/), for example, recommends non-fast-forward). –  Apr 25 '13 at 14:40
  • It's generally considered best practice to keep the version history as topologically simple as possible, which means to use fast-forward. The --no-ff option is there to support methodologies that demand explicit branching and merge tracking. – antlersoft Apr 25 '13 at 14:46
  • 1
    Our best practice is that the master branch is never "broken". Meaning I can go to any commit and have a valid and functional build. Branches may contain commits that may not be functionally complete, or may not build for that matter. In these cases, we prefer not to fast forward. – CodeNaked Apr 25 '13 at 14:50