Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've been following the successful Git branching model guide for most of my development. I still wonder if the way I handle bug tickets is correct.

My current workflow: Once I accept a bug ticket I will do a git checkout -b bug/{ticket_number}, create a single commit as a fix and then checkout develop and do a git merge --no-ff.

I'd love to hear from the experiences of others whether or not I am abusing the --no-ff option in this instance. If I am, could someone suggest a better approach?

share|improve this question
2  
This seems like a great approach. –  Daenyth Jun 7 '12 at 20:02
    
The only thing to add is that if your project has several release branches then you should check out the bug/hotfix branch out of that (i.e. fixing bugs on a previous release). –  Spoike Jun 8 '12 at 16:42
1  
This answer to another question about fast-forward merges is excellent and may help you decide if your outlined workflow is the best way to represent your bugfixes in the Git history: stackoverflow.com/a/2850413/81234 –  jmlane Jun 8 '12 at 16:47
    
Why do you think the use of that option counts as abuse? –  Mark Canlas Jun 8 '12 at 20:01
    
@MarkCanlas I have a lot of single commit bug fixes and so I'm doubling the amount of commits in history to include the merge commits. I wasn't sure if I was spamming the history with merge commits. –  kisplit Jun 10 '12 at 22:21

1 Answer 1

up vote 3 down vote accepted

You don't need to do all your work as a single commit; you can commit multiple times and squash the commits when you merge back into the original branch (which is the default merge behavior). If the bug is significant, that might be helpful.

Also, if the branch is open for a long time, you might want to rebase the branch (basically, recreate the branch from a newest root version and apply your changes again); this will update the branch with the upstream changes and you'll be able to verify if any change upstream has broken your bugfix.

After you have pushed your branch upstream, however (in case you do that), rebasing is not recommended. You can create a new branch from the root and merge your old branch into the new. This seems to work, but I'm not sure if it's correct.

share|improve this answer
    
I'm currently rebasing -i to make squashes when it's a long bug fix but many of these bugs are only 1-10 lines of change. –  kisplit Jun 10 '12 at 22:24

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.