如何使用Git分支/合并来克服开发分支中的bug提交？

Question

I'm looking into different Git branching strategies and I keep getting stuck at one point. Let's say you have a master branch. Additionally, you have a develop branch, which is a branch from master. There are feature/topic branches:

• FixFrontEnd
• FixBackEnd
• ChangeConfig

Three different developers do each change. The ChangeConfig developer finishes quickly, commits, and merges into the develop branch. That develop branch is now built and deployed to the Dev environment. Someone tests out this new config and it's approved to move from Dev to the QA environment. The same success is found for the FixFrontEnd and FixBackEnd branches. They eventually move along up to QA.

Priorities change the next and the three fixes/features are left sitting in QA. A new YetAnotherChange fix/feature makes it to QA. We've found issues with FixFrontEnd and ChangeConfig in QA. However, YetAnotherChange must go to Production ASAP.

Everything I'm reading says that the develop branch is merged into the master branch, a new build is created for production using master, and it's deployed. Wouldn't FixFrontEnd and ChangeConfig get dragged along in the merge to master? How is everyone approaching this?

Cherry picking seems to be a complex choice. I'd like some good idea on how to solve this issue. I'm looking for a simple solution. Additionally, let's say that we were able to cherry pick commits. How can we truly trust that what's cherry picked and built in will work the same way as it did when we built using the develop branch? Am I getting lost in the woods here somewhere?

Answer 1

So you want to make changes to production without changes from FixFrontEnd and ChangeConfig branches . You can use the way to fix it. Let's illustrate by below graph:

A---B---C master
 \
  D----E----F----G ----L  develop
      /     |     \     \
     H      I      J     K

Assume commit histories from each fix/feature branches as:

ChangeConfig: H and then merge to develop branch

FixFrontEnd: I and then merge to develop branch

FixBackEnd: J and then merge to develop branch

YetAnotherChange: K and then merge to develop branch

You just need to find the commit ID for D, F and L, then use git rebase --onto <commit id for D> <commit id for F> <commit id for L> , the develop branch will not contain the changes from FixFrontEnd and ChangeConfig branches. And it can go to production. The graph will equal to:

A---B---C master
 \
  D ----G ----L  develop
         \     \
          J     K

note: during rebasing, there may has conflicted file, you need to use git add <conflicted filename> and git rebase --continue , then the rebase will go on.

Answer 2

Everything I'm reading says that the develop branch is merged into the master branch

Not really: you can:

• rebase YetAnotherChange on top of master (and then fast-forward master to YetAnotherChange HEAD)
• merge master back into develop
• rebase the remaining feature branches on top of develop .

Any rebasing operation will change the history of those branches, so it needs to be done with a good communication to the developers working on those branches for them to reset their working tree to the new branch HEAD.