Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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 before deleting the feature branch

Tree visualisation in SourceTree after deleting the feature branch: Tree 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:

Tree visualisation on the command line

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:

Straight tree line after --squash

Question

  1. 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.

like image 782
Lernkurve Avatar asked Sep 24 '15 20:09

Lernkurve


People also ask

Do you delete feature branch after merge?

When you're done with a branch and it has been merged into master, delete it. A new branch can be made off of the most recent commit on the master branch. Also, while it is ok to hang onto branches after you've merged them into the master they will begin to pile up.

What happens to feature branch after merge?

The answer is: nothing happens to the feature branch as a result of the merge. The new merge commit is added on the current branch (which is master when the merge is done).

Can't delete branch checked?

Delete a local branch You can't delete a branch if you're checked out that branch. You will see this error: Cannot delete branch 'branch-name' checked out at 'some-location'. To fix this, you will have to switch to a different branch. -d is shortcut for —-delete and it deletes a branch.


2 Answers

  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.

  1. 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)
like image 123
topheman Avatar answered Sep 22 '22 10:09

topheman


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.

like image 44
merlin2011 Avatar answered Sep 21 '22 10:09

merlin2011