Why is the Git feature branch still visible after merge and deletion?

Question

Steps taken

I merged a feature branch back into master and deleted the feature branch. But it still shows up in the tree.

Result

Tree visualisation in SourceTree before deleting the feature branch:

Tree visualisation in SourceTree after deleting the feature branch:

The feature branch in the left-hand list is gone, as expected, and the label in the tree visualisation is gone as well, again as expected.

Questions

But:

1. Why is the violet part still shown?
2. Which Git commands would I have needed to execute to not see the violet part anymore? I probably answered this question myself two sections further down.

I understand that the final commit in the screenshot above has two parents. But I don't understand why the violet commit which happened on the feature branch is not inside the final merged commit on master (which would, I think, mean that the violet branch shouldn't be visible anymore after deleting it).

Replay of steps from the command line (instead of SourceTree)

I replayed it on the command line (just to check whether SourceTree did what I thought it did) and the final step was a git merge feature. Same situation:

Trial with --squash

I undid the last merge and tried this:

git merge --squash feature
git commit "Squashed merge"
git delete -D feature # Note that -d did not work; it said "error: The branch 'feature' is not fully merged."

And now it shows what I would have expected in the first place. One straight line and no indication of the feature branch ever existing:

Question

3. How is this merge different from the previous merge?

I guess I sort of pieced together what happens with those merges after all the trial and error above, but I would be grateful if someone could really explain in detail what the semantic difference of the above steps are.

Answer 1

When you delete a branch, you're deleting a pointer to a commit, not the commit itself. If there are no other references to the commit, then the commit can eventually be garbage-collected, but the merged commit creates a reference to that commit (since that commit is its parent).

The initial merge workflow creates a merge commit with two parents, and the second parent commit still exists even if the branch pointing at it does not.

When you do git merge --squash, you are effectively causing a rebase of your commit onto the target branch, which gives you the linear history instead of the dual-parent history. For the distinction between that command and rebase, take a look at this question.

Answer 2

1. You still see the violet part because you dit a git merge, which creates a merge commit assembling the two branches. Since branches have diverged, this is a "non fast forward" merge, this is why the history will still show this kind of tree.

2. You don't want the violet part ? Use git rebase instead of git merge. In your case:

   • git checkout master
   • git rebase feature
   • git branch -d feature

This will replay the commits of feature on master before the divergence. You'll have a straight line in your history log.

3. You did a git merge --squash which quite alike a rebase - but you're squashing all the commits of the source branch in one commit (in your case you only have one commit, so it doesn't really show)