Reconciling Branch-per-task and bug fixing when the bug was fixed and merged to trunk, but the bug was not actually sufficiently “fixed”

Question

I’ve recently switch from CVS to Plastic for source control. We use Jira for issue tracking, and Plastic branches to link change sets with open issues. With the switch, I’ve also adopted the branch-per-task approach to development. This has lead to an interesting dilemma when it comes to fixing bugs that have been re-opened (a new test case has discovered the bug was not fully fixed after an iteration/release to test)

I’ve fixed a bug, ran my tests (available at the time) against it and it passed. I merged the code, and developed a second feature that touched the same file. Both changes have been done on different branches, and both were successfully merged into the main build branch. The new build goes to QA and they discover a slightly different way to re-produce the same issue (a new test case) and re-open the bug. The original bug branch does not include the new features added to the same file because they are on different branches (e.g. bug 1 fixes are part of feature 2 branch [as this branch was created after the original fix was merged to the build branch], but the new feature 2 code is not on the bug 1 branch)

Given this scenario: What is the best practice for bug fixing when the bug has been re-opened and you are using the branch-per-task approach?

• Would it be better to clone the bug in Jira to create a new issue
  number, create a new branch and re-fix the issue as if it is new?
  [this would essentially base the new fix on the combination of the
  original fix + the new feature] (Would this make it harder to merge
  across versions if you had to track multiple fixes for the same
  issue?)
• Would it be better to go back to the original branch where the
  original issue was fixed, and re-fix it, then merge again, dealing
  with conflict resolution every time this sort of thing happens?

Note:

1. Branches are created to link with a bug tracking system (Jira), so the branch names include the issue number.
2. Because of this link, I can’t create 2 branches with the same name unless they have different parents. So, I could create a second branch from the original, but not from the build branch (which is the parent of the original issue)

It seems that the branch per task method would cause conflict resolution to occur repeatedly between the bug fix and the feature until both were completely tested and resolved, since there is no merging across these task branches – only to the trunk, they will both be continuously “out of date” with each other.

I’m betting this will not be a common occurrence for a single developer, but it may occur more often with larger teams, even if it is not specifically between a bug and a feature (conceivable, two features could affect the same file(s), causing additional conflict resolution during the life of the build/test cycle before release)

This process works almost the opposite of how the team used CVS in the past, so I’m trying to find the “right” way to do it to minimize the pain of moving forward with the new model. Before, I would just go get the latest changes from the last build and make the new fix – thus, avoiding any conflict resolution issues (but I don't get the benefits of branch per task).

Now, I have to think of what branch the "original" fix was done on, and if that is the correct place where the "new" fix needs to go to keep the issue tracking system in sync with the change set list.

Answer 1

there're multiple alternatives and solutions for the situation you're asking, I'm going to explain my favorite one for each situation I can think off:

(1) The 2 branches are integrated in the "Release branch" AKA "/main" and you don't want to subtractive them.

In this situation you have to create a new task in Jira, link it to the task that has caused the issue and set it as a regression if it's the case.

Now that you have a new task in Jira you can create a new branch in Plastic. This new branch will base from the last cset/label in the "/main" branch.

Develop the fix and integrate it in the next release when it has all the QA on green.

(2) The tasks can't remain in the "Release branch" and they must be subtracted

You will perform a subtractive merge of the changesets created in the "/main" branch, so the "Release branch" will be reverted to an stable point.

The Jira task is reopened, even re-estimated.

The developer will continue the work in the task branch to adequate the code with the new requirements.

Once the task is complete the regular branch-per-task cycle goes on.

Hope it helps!