Identifying branch of commits in Git after deleting a branch

Question

I'm in the process of switching from subversion to Git, and I'm trying to get a better understanding of how I should manage branches.

Say there is a bug in my software which is recorded as Issue 123 in my bug tracking system. I may create a new branch in git to fix the bug called "issue123". I commit a few changes to fix the bug, and merge it back into the main development branch.

At this point is sounds like I should delete the branch. The commits associated with the fix will remain in the repository, bit since issue 123 is resolved I no longer need the pointer to the branch.

So my question is if I delete the branch after merging is there any way later to find where I fixed issue 123? Or should my merge commit message be something like "merging issue 123 fix"?

Answer 1

Once you merge the side branch "bug123" to - lets say "Main", The merging itself will be a commit called "Merge branch bug123". You don't need to name it. The merge commit will contain all the changes you have done to fix "bug123".

Answer 2

If you want to see the specific history of that particular branch, you can always select a non-fast-forward merge when you merge it back in. That way other work in the main development branch will not be co-mingled with the history.

git merge --no-ff

Another way is to squash the feature branch down to a single commit before merging it into the main development branch. This has the advantage of allowing fast-forward merges and still keeping the changes for the feature branch distinct from other development work. The downside is that you lose history from within the feature branch.

git merge --squash

In either case, you can force git to always create a merge commit and leave a reasonable commit message about the merge and the issue it relates to.

git merge --commit

I recommend creating some local branches and playing around with all the options to see how they affect your repository.

Answer 3

Merges automatically fill in a message, like "Merge branch 'feature' into branch develop". I always leave these messages intact, so I can see what the branch that merged in used to be called. It's the only place this information is guaranteed to remain. If you delete these merge messages and the branches, that's it. You can't figure out what was what ever again.

I will checkout a new branch for some feature, work on it, then switch back to whatever branch I branched from - often master, but not always - then git merge --no-ff <feature branch>. Here are some example commits from a project in which I've been rigging a character for animation:

* c117bff Make squash joint scaling uniform
* 9eb9ac2 Fix eyelid control limit
*   b50c967 Merge branch 'lipWeightImprovements'
|\  
| * 6f98ea7 Smooth cheek weighting
| * fdf3f91 Improve lip weights
|/  
*   4434223 Merge branch 'hair'
|\  
| * a3f3f89 Add hair controls for front half of head
| * 22a6bf4 Add joints for and weight front hair pieces
|/  
* c338c14 Move archived script into archive/scripted folder

Note the two merge branches - each says "Merge branch 'whatever'". That's a unique aspect of the master branch, which I'm not really big fan of. If you merge to master, it doesn't put master in the merge message. If I had merged to, say, the 'release' branch, it would add "into release" to those messages. Even though I deleted the branch heads later, the merge messages tell me what those branches used to be called.

There are two things of note here:

1. This graph was produced with git log --all --decorate --graph --oneline (those flags can be in any order). This group of 4 flags is so common that most people alias them, and I've seen all manner of alias names. I use la for 'list all', and it's just those 4 flags. I also have las and lass for 'short' and 'super short' versions, and those just tack on, e.g. -10 and -25 flags, which are different numbers per machine I work on. I like las to show a bit under half a screen's worth of listings, and lass to show just under a quarter's worth. I also have lb - 'list branch' - versions of those, which just leave off the -all flag, so it only lists the history of the branch I'm on.
2. When you make a commit, that moves to the top-left of this graph. The line of commits straight down the left side will be the 'first parents', meaning the commits that were merged into back through the history of your current branch. All branches that merge in come in from the left, always. Git will even draw a line through other lines to the right so it can wrap around the left in some cases, just so branches merging in always come in from the right, and merge in to the left. In this way you can always figure out what's going on in your history.

If you want my la/lb aliases, just run these commands:

git config --global alias.la 'log --oneline --graph --all --decorate'
git config --global alias.las 'log --oneline --graph --all --decorate -20'
git config --global alias.lass 'log --oneline --graph --all --decorate -8'
git config --global alias.lb 'log --oneline --graph --decorate'
git config --global alias.lbs 'log --oneline --graph --decorate -20'
git config --global alias.lbss 'log --oneline --graph --decorate -8'

That'll set it up for all repos (via your ~/.gitconfig file). Tweak the numbers to taste.

Answer 4

You don’t have to delete the branch, but it is a good practice indeed to archive it and de-clutter:

$ git tag archive/branch branch
$ git branch -d branch

_{See How can I archive git branches?}

When you tag the branch and delete it, you can still find via the tags but it will not show in the list of branches.

So my question is if I delete the branch after merging is there any way later to find where I fixed issue 123? Or should my merge commit message be something like "merging issue 123 fix"?

You should definitely use meaningful merge messages, e.g. “merge fix_123 into master” whether you delete the branch fix_123 or not.

When you have a good way for naming fix, develop, staging, etc branches, then the merge messages are self-descriptive, as the use the branch names by default.

And to answer your first question, if you tagged the branch before you deleted it, you can find where you fixed issue via tags.