Suppose we have an application that\'s stable.
Tomorrow, someone reports a big ol\' bug that we decide to hotfix right away. So we create a branch for that hotfix off o
It seems that you want to delete the 2011_Hotfix
branch without losing its history. I will discuss deletion first and history second.
The usual git
branch deletion methods have already been described above, and they work as expected. git
does not have a one or two word command that means, "Hey git
, delete both the local and remote branch." But this behavior can be mimicked via shell script. For example, take Zach Holman's shell script 'git-nuke'. It is very simple:
#!/bin/sh
git branch -D $1
git push origin :$1
Put this in an executable file (e.g., git-nuke
) in one of your $PATH
directories. If you're not on the 2011_Hotfix
branch, you simply running git-nuke 2011_Hotfix
will delete both the local and remote branches. This is much faster & simpler--though perhaps more dangerous--than the standard git
commands.
Your concern about preserving history is a good one. In this case, you needn't be worried. Once you merge 2011_Hotfix
onto master
, all commits from 2011_Hotfix
will be added to master
's commit history. In short, you will not lose history from a simple merge.
I have one more word to add that is perhaps beyond the scope of your question, but is relevant nonetheless. Let's imagine that there are 20 tiny, "work-in-progress" commits on 2011_Hotfix
; however, you want only one complete commit for 2011_Hotfix
to be added to master
's history. How do you combine all 20 small commits into one big commit? Fortunately, git
allows you to consolidate multiple commits into one commit by using git-rebase
. I won't explain here how that works; though, if you're interested, the documentation for git-rebase is excellent. Do note that git rebase
rewrites history, so it should be used judiciously, especially if you are new to it. Finally, your 2011_Hotfix
scenario is about a dev team, not a solo dev. If project team members use git rebase
, it is wise for the team to have explicit guidelines on the use of git rebase
in order that some cowboy dev on the team doesn't unwittingly damage a project's git
's history.