CODEWITHSUNDEEP
gitgit-branchgit-merge
Tomek
Tomek

Reputation: 641

Git: should merged branch be always deleted?

I have a question related to git merge workflow.

When we merge one branch to another, AFAIK two things may happen: either a single commit would be created on the destination branch (in non fast-forward case) or commits from the merged branch will be applied "on top of" commits on the destination branch.

I am especially interested in the fist case. While in the second case all history of changes is transfered to the destination branch, in the first case, the history is "squashed" into a single commit. As a result, if we remove the merged branch, we have only a single commit incorporating all the changes from the branch. On the other hand, if it happens that the merged branch was originated from the destination branch, AFAIK, every rebase of the destination branch would require rebase of the merged branch to keep them in-sync.

My question is: should we always delete merged branches or there is a way to keep the merged branch and prevent from rebasing it every time it's "root" branch is rebased?

Rationale for keeping the merged branch is that in such case we have insight into detailed history of changes done on that branch.

Upvotes: 2

Views: 538

Answers (3)

gjcamann
gjcamann

Reputation: 651

Where I work, we use this as our workflow model. When we implement a change we create a feature branch and put in an empty commit to describe the branch. 

git checkout -b feature1
git commit --allow-empty -m "Create branch to add a menu."

When we're done with this work, or hit a good stopping point, we merge in the feature branch (non-fast-forward) and delete the feature branch.

git checkout develop
git merge --no-ff feature1
git branch -d feature1

The branch history is still retained as a "lane change" under gitk. This allows us good visibility in what was changed for that feature, but avoids cluttering up the list of branches we have.

Upvotes: 1

Michael Wild
Michael Wild

Reputation: 26351

Unless you use the --squash option in the git merge call, the branch information of the merged branch will be preserved. The newly created merge commit simply has two (or more, in case of an octopus merge) parent commits instead of a single one. The first parent corresponds to the branch you merged into, the other parents represent the branches that were merged.

You can visualize this using e.g. the gitk tool, or by e.g. using

git log --pretty=oneline --abbrev-commit --graph --decorate

So, in case of a normal merge (non-squash, no matter whether fast or non-fast forward), you can easily keep your original branch and continue developing with it. If you squashed, a future non-squash merge will be potentially very confusing for the posterity, so it might be a good idea to use git reset --hard on it or git rebase in case you already have new changes.

Upvotes: 2

Andreas Wederbrand
Andreas Wederbrand

Reputation: 40011

When you merge you have a choice of squashing it or to leave it as it is.

I would say that if you squash it just go a head and delete the branch as it has clearly done it's part after it was squashed.

If you leave the branch intact (no squashing) you can leave it and reuse it if you need.

Generally I would only squash commits if the history is useless or even wrong. I've done development where commits fail to build that where fixed later. Those commits should be squashed away before the merge.

Upvotes: 1

Related Questions