Menu
What are the current best practices with git branches that have been created to test out a solution to a bug and have not been merged because the review process show that they are wrong or there are better solutions to the problem?
An example. Project fizzbuzz has a bug report that reports a crash on empty fields.
handle-empty-fields and make two commit to that branch, "solving" the problem.Now the code in the handle-empty-fields my code is useless: it is not correct and cannot be applied any longer to the code, but it has been referenced in that bug report.
What should I do? Keep the branch? I will quickly end up with dozens of abandoned branch and git has no way to mark a branch as abandoned or closed. Remove the branch? But then people looking at that bug report will find it and get 404.
People are often suggested not to rebase their repositories because that will cause problems to other devs, especially downstream devs. What are the suggestions for feature or bug-fix branches?
Update: it looks like github never deletes the commits contained in pull requests. So, if you push your changes an turn them into a pull request, you can later delete the branch without losing any of your changes. Well, while github is still working ;).
683
They're unnecessary. In most cases, branches, especially branches that were related to a pull request that has since been accepted, serve no purpose. They're clutter. They don't add any significant technical overhead, but they make it more difficult for humans to work with lists of branches in the repository.
So basically the only reason to keep hotfix branch after a merge is if you plan to make any more changes to the same hotfix, which doesn't make much sense once you release the hotfix. So you should feel perfectly safe deleting the branch after the merge.
Yes, it is generally a good idea to preserve feature branches for a while, at least until you are 100% sure you will never go back. It doesn't hurt anything or take up any resources. A branch is only a little sticky note pointing to a commit.
Additionally, git will warn you (and refuse to delete the branch) if it thinks you didn't fully merge it yet. If you forcefully delete a branch (with git branch -D) which is not completely merged yet, you have to do some tricks to get the unmerged commits back though (see below). There are some reasons to keep a branch around though.
You can create a branch from a previous commit on an existing branch. Remember, a commit is just a snapshot in time of the files in a repository. You create a branch from a commit if you want to work on a specific snapshot of the files. Before creating the branch, you need the SHA-1 identifier of the commit.
Multiple people create separate branches to work on their code and merge their changes into the main branch. Branches are meant to be temporary and should be deleted when work is completed. Branch names can be anything you’d like.
Merging takes your branch changes and implements them into the main branch. Depending on the commit history, Git performs merges two ways: fast-forward and three-way merge. Let’s examine both of these based on the branches and commit history in the following diagram.
The way I do it is to give it a tag. Use a full tag and give it a descriptive name. Then you can delete the branch, so it doesn't show up in your branch listings, but because it's tagged, the branch can still be recreated by checking out the branch. All the commits on the tag will still be available, and you won't lose any commits in a git gc Something like this, perhaps:
git tag -a partialBugfixXXX -m"Tagging a branch that went into fixing bug XXX" If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
