11

We're using a A successful Git branching model by Vincent Driessen for our branching model. All's fine but I haven't really seen a particular issue brought up.

From what I've understood, when a new feature is required, you branch of the development and create a new feature branch. You would work on this and when you're done, you would merge this branch into the the development branch.

What if a developer makes a feature and then merges that feature back to development only to be found out that there's some bugs in the feature code. Where should this be fixed? Should a new fix/bugfix branch be started from development and the code be fixed there? I can't see another way.

How should one go about this?

Thanks

Mridang Agarwalla
  • 43,201
  • 71
  • 221
  • 382
  • I seem to have created a duplicate of your question, however in my question I've taken an approach of providing commands to create an experimental repo for testing the concepts: http://stackoverflow.com/questions/32244693/changes-on-feature-branch-after-merge-to-master/32244878?noredirect=1#comment52371049_32244878 Would you mind if I extend your question with the example repo, and see how would the suggested answers actually be applied on to that repo and with what result? – TheMeaningfulEngineer Aug 27 '15 at 10:09

4 Answers4

12

Remember that a model is just a model - it's about giving you a structure that makes you more efficient, not blindly following a set of rules. That means that you should feel free to tweak things and figure out what works in your situation, because it may not work in every situation.

I think you have a choice in this situation:

  1. Roll back the merge and continue work on the feature branch until it is ready
  2. Start a new branch to fix the bug.

Which one you choose depends on factors like:

  • Can your customers see the bug? Make a bugfix or hotfix branch.
  • Is the bug really bad and stop other progress on the development branch? Roll back the change.
  • Is it only a minor issue with minimal external impact? Simply continue work on the feature branch and merge again when ready.

The difference between a feature branch and bugfix branch isn't important from Git's point of view. It only matters if you use those labels for internal documentation or other auditing purposes (e.g. to keep track of what is visible to external users).

Resist the temptation to work straight off the development branch even if you think the bugfix will be very quick - nothing is ever quite as simple as it seems, and you will give yourself a headache later if anything goes wrong.

Rough visual representation of your choices:

State machine diagram of choices

Brian L
  • 3,201
  • 1
  • 15
  • 15
5

How about finding the commit that introduced the bug, and creating a new branch rooted there? With this approach:

  • There's no risk of creating broken references due to rebase operations
  • Just from the ancestry of the development branch, the feature branch, and any other branch that may be affected, you can tell where you should merge your bugfix branch once it's done. This is true even if "feature" has merged with "development" several times since the introduction of the bug.
  • If you identify the commit that introduced the bug, and root from there, developers will be able to tell where they need to merge the bugfix branch, even if they're not familiar with the repo layout
  • You'll have a branch that you can merge without fear of pulling in unrelated subsequent changes. For example - let's say someone is working on "feature-beta" which is a sub-branch of "feature" that diverged shortly after the bug was introduced. They can pull in the bugfix branch easily, without worrying about also pulling in everything else that has occurred on "feature".
  • This approach reduces the need to cherry-pick, which has the downside that it changes the name of commits (thus undermining one of git's great advantages, which is applying an unambiguous name to everything.)
gcbenison
  • 11,723
  • 4
  • 44
  • 82
  • +1000. I also think this is the most advisable approach. It leads to a very clear commit history. On the opposite side, cherry-picking is the most opaque approach since it completely hides where the bug was introduced and where it was been fixed. Also note that git bisect helps a lot in finding the commit that introduced the bug. Definitively a highly suggested approach. – Arialdo Martini Oct 09 '12 at 09:28
1

If that feature branch is a public one (i.e pushed to a remote repo which is cloned / used by others), it is best to make a new branch and isolate the debug in said fix branch.
(instead of trying to rebase 'feature' branch on top of 'develop' branch).

The idea remains to not record intermediate debug commits directly in develop branch, but to record only the resulting commit that will fix the bug introduced by feature branch merge in the first place.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

Just make a branch (or use the old, merged feature branch) and fix it there.

Using the old branch / create new branch is just the same --- you can't name which is which after merged.

J-16 SDiZ
  • 26,473
  • 4
  • 65
  • 84