1

I have a large web application project that has, essentially, just one branch - Master. However, I will create a new branch for a bug fix, then merge that branch into the master branch. Easy Peasy.

I want to do a large user interface overhaul which will take a while to complete - weeks, if not months. However, during this time I will still need to be doing bug fixes along the way.

I'm trying to understand logically how this can be done. Do I simply create a "UIUpdate" branch, doing all my UI updates there, and at the same time create and merge bug fix branches? Once the UI overhaul is complete, can I simply merge that branch into the master branch and assume it won't overwrite all my bug fixing code?

My brain is having a hard time understanding how this would be possible.

Thanks

Garfonzo
  • 3,876
  • 6
  • 43
  • 78

3 Answers3

2

I think your real question is something a little different. When you make your small bugfix branches, you probably only make commits on the bugfix branch, and then when you merge it into master, you are probably getting a fast-forward merge and a completely linear history. Now you have a master branch and a new feature branch, and you are making commits on both branches: bugfix commits on the master branch, feature commits on the feature branch. Now you realize that when you want to merge them, the history will not be linear anymore, and you're not sure what's going to happen.

If the above describes your problem, then you would probably be best served by reading an introduction to Git's branching model, such as this one. The good news is that this situation is exactly what git's branching and merging model is designed for.

The short answer is that as long as your bug fixes and your new feature changes don't modify the same lines of code, git will just merge them together, as if you had made the changes one after the other. If they do touch the same lines of code, you will need to resolve the merge conflict (which you can read about at the above link). Lastly, it's possible that your bug fixes and feature code don't touch the same lines, but still have a logical conflict. For example, if your bug fix adds a reference to a variable and your feature code renames that same variable, then in the merged code you will have a reference to the old variable name that you will need to fix, and git will not be able to tell you about it.

Ryan C. Thompson
  • 40,856
  • 28
  • 97
  • 159
  • The main point I take from your response, which I think helps me understand logically what's happening, is when you say "as long as your bug fixes and your new feature changes don't modify the same lines of code, git will just merge them together". I think this nails it for me. Of course, your further explanation helps too. Understanding that so long as my editing isn't changing the same code in two different branches, I'll be OK. Further, even if I do edit the same code, I can resolve the conflicts fairly easily (I've run into this situation before, so it makes sense.) Thanks for this. – Garfonzo Jul 23 '13 at 22:58
1

Yes, you can do exactly that. Git is designed to allow for multiple branches to coexist quite easily. You would create your new branch as followed:

# running this operation while on master
git checkout -b this_cool_feature_Im_working_on

Now the important part is keeping this_cool_feature_Im_working_on synced up with master, but not necessarily the other way around. I would suggest that every time you create a bug fix and then later merge that into master that you also then go and merge that bug fix into this_cool_feature_Im_working_on as well. This will make sure that this_cool_feature_Im_working_on knows about the changes that are still happening on master. This is important because this minimizes the difficulty of handling merge conflicts when they occur. this_cool_feature_Im_working_on will be relatively close to master because the changes made on master are sent to this_cool_feature_Im_working_on. This keeps your work organized. You will not be able to prevent merge conflicts from happening, but don't be afraid of them, resolving them is part of git's workflow.

When you are ready, you can merge this_cool_feature_Im_working_on back into master. If you have been merging master into this_cool_feature_Im_working_on regularly then when you finally go to merge this_cool_feature_Im_working_on back into master this should only generate a few small and easy to resolve merge conflicts, possible none. This work pattern allows separate feature branches like what you are talking about to exist. It also assumes that the team will be ready to hand resolve the small merge conflicts that can occur, but once again I stress that resolving merge conflicts is easy in git and part of the intended workflow to a greater degree than in a CSV like snv.

usumoio
  • 3,500
  • 6
  • 31
  • 57
  • That's a great tip - merging `bug_fix` into the `feature` branch to keep it in line with the `master` branch. This will surely make the final merge of `feature` into `master` relatively painless. – Garfonzo Jul 23 '13 at 23:01
  • @Garfonzo indeed, doing exactly that is an indispensable part of my work flow when doing this type of merging. It's saved me 10s of hours of work resolving merge conflicts – usumoio Jul 24 '13 at 00:20
0

Your bug-fixes won't get overriden once you merge, but that does not guarantee the merge will go smoothly. For example, if a you need to change the signature of a function as part of a bug-fix and the new UI code uses that function - obviously that'll crash your project. And that's an easy case - more subtle fixes will be harder to fix once you merge the new UI.

A better approach would be to merge the fixes from master(or directly from the bug-fix branch) into the new UI branch after each bug-fix. That way, the bug-fix is still fresh in your memory, so if it breaks the new UI it'll be much easier for you to fix that than months later, when you merge the UI.

Another important benefit is that if it turns out that the conflict can't\shouldn't be resolved from the new UI code, and you have to fix the bug-fix itself in order to make it work with the new UI, you can do it right away(in the bug-fix branch, ofcourse - not in the new UI branch!) before any new code depends on that bug-fix.

Idan Arye
  • 12,402
  • 5
  • 49
  • 68