Git - 功能分支之间的冲突 - 如何避免功能分支包含另一个功能分支中的更改

Question

The scenarios is as following. I will use t1,t2,t3 and etc. to represent different time:

I have two branches to represent my environments DEV branch, MASTER branch.

t1: I created a Feature_001 branch from MASTER

t2: I added commits in the Feature_001 branch and merged my code into DEV and pushed it.

t3: for some reason, my manager told me to stop the development of the Feature_001 branch

t4: One month passed. My colleague Clair created a Feature_002 branch from MASTER.

t5: Clair added commits in the Feature_002 branch and attempted to merge her code into DEV branch and pushed it. However, a conflict shows up when she pushed.

t6: Clair then pulled and merged the changes from the DEV branch into her Feature_002 branch ( my problem happens in this moment ). She made a new commit to solve the conflict in the Feature_002 branch. After that, Clair merged her code into DEV and pushed.

t7: After testing, Clair's manager says it's OK to merge into MASTER branch now. So, Clair merged the Feature_002 branch into the MASTER branch.

t8: Although the Feature_002 Clair developed is functioning in the production, the Feature_001 unintentionally shows up in the production, too, because the Feature_002 branch once merged code from DEV to itself to solve conflicts. Our manager was shocked and started to question who dared to let the Feature_001 go out to production??

t9: meeting and meeting forever to discuss what happened...

If you follow well on the scenario, you can find because of the conflicts between feature branches, Feature_002 branch will include changes in the Feature_001 branch after Clair pulled the code from DEV.

My question is how to keep two feature branches independently while enabling us to solve conflicts between them ?

Any feedback and discussion is much appreciated.

EDIT 20180925:

I want to adjust the situation a bit. Feature_001 branch can be unwanted or just be under development for a long time. Let's make it be under development for a long time while Feature_002 was tested first and merged into MASTER real quick. However, now, again, MASTER branch have both Feature_001 and Feature_002 changes there when we don't want Feature_001 to be in production.

Answer 1

I see a number of problems there. If feature 001 was not to be developed anymore.... even discarded, say, it should have been taken out of dev branch. Given that it wasn't, when you merge dev (through feature 002) onto master (yet another problem, my guess is that this shouldn't happen) then, because feature 001 hadn't been taken out, it landed in master.

So.... how to avoid it? Everybody will say a different thing. My take? When you got the notice that feature 0001 was to be stopped, it should have been taken out of dev branch (either by rewriting dev history to avoid the merge or by reverting 0001 revisions). And then, I guess you shouldn't merge from dev into master... but that's just a guess cause it really depends on your workflow.

Answer 2

If the changes from Feature_001 weren't intended to be released to production, it shouldn't have been merged to DEV. The changes should have been left on the Feature_001 branch. If the decision to not release Feature_001 was made after it was merged to development, the changes should have been reverted. As long as it is present on DEV, other users who pull from DEV will have the changes in their branch.

Answer 3

The branch Feature_001 shouldn't have merged to DEV until Feature_001 was completed and pull request approved. The conflicts will have to be resolved once Feature_001 is merged into DEV not before, this will avoid the problem you encountered, where Feature_002 branch had some commited code from Feature_001. Ideally the Feature_001 should either be small or broken down into smaller features such as Feature-001-S-xxxxxx-MyStoryDescription for easy tracking. Additionally, since your branch Feature-001 might have many commits, it is recommended to squash your commits before doing pull request and rebase your branch when a merge conflicts occurs. Happy coding!

Answer 4

I understand that you are not using GitFlow, because you created your feature branches since master (in Gitflow it should be develop), and you are pushing changes not ready to be released in develop (in GitFlow, the release branch is created since develop).

Hence, thinking in your actual flow, to avoid these issues we can:

1. Avoid to push changes not ready to production to develop. Test your code in your local machine. If you really need to test your code in some specific environment, "borrow" the environment and deploy your feature branch only.

2. Create features that only works if some flag is activated, for example a flag FEATURE_ACTIVE in db. It should have the value Y in qa (to test) and N in production (to avoid issues).

3. NOT RECOMENDABLE. If for some reason, you still need to push changes not ready for production to develop. When you face a conflict, you can create a temporary branch that solves the conflict between two branches and then, merge it to develop. This allows you to maintain the branches independently. The author of the branch that will be deployed later, should be aware of the merge of the other branch to the branch master, after that he can pull the changes from master and also merge the temporary branch into it to keep the branches clean. For example in this case, your friend should have created a new branch since Feature_002 called Feature_001_002_temp and then merge the branch Feature_001 into it, solve the conflicts and merge it to develop. Any additional change to Feature_002 should pass throug this temporary branch until Feature_002 goes to prod. Be very careful with the changes, some conflicts such as deletions, values of constants could break your app.