我一直在监控从每个sprint开始的两个分支 - Release和Master。
Master分支来自开发人员创建新分支（特定于任务），实现其更改，并创建拉入请求，并将其合并到Master。
Release分支是sprint特定的，仍然可以提交给生产。我们只将提交到Master并由QA验证的分支合并到Release分支中。
这种方法最适合我们，因为我们定期修复Release并且已经实施并验证了特定功能，因此我们确切知道下一版本中会发生什么。
在我遇到以下问题之前它会变得很好;
taskA创建了特定于任务的分支Master。taskA分行。taskB创建了他的分支Master，并对taskB进行了多项更改，并将taskB合并到Master。Master合并到taskA分支并继续执行其任务，并对taskA分支进行更多更改！taskA分支合并到Master。现在我只想将taskA分支合并到Release分支，但由于taskB也被合并到taskA分支，因为DeveloperA将Master合并到他的分支中在步骤＃4中，我将taskB分支自动更改为Release分支！我不想要那个。
避免将Master合并到Developer分支中的最佳方法是什么？在我的案例中可能采用哪种正确的方法？
答案 0 :(得分：2)
我认为你的策略太复杂，容易出问题。复杂的是尝试将功能分支分别集成到Release和Master中。由于功能是在Master上开发的，因此每个功能分支都将使用早期功能和错误修复。当您尝试将功能分支单独合并到Release时，Release可能没有集成早期功能和它依赖的错误修复。问题，冲突，并发症。
如果您从Master中创建功能分支，将它们合并到Master中，并定期将Master合并到Release中，则会简单得多。合并流程是功能 - ＆gt;大师 - ＆gt;发布。永不特色 - ＆gt;发布。实际上，应该有中间的测试和暂存分支来保存当前正在进行最终用户测试的版本（这是在功能分支单元测试之上），以及为下一个版本准备的内容。特点 - ＆gt;大师 - ＆gt;测试 - ＆gt;分期 - ＆gt;释放。
那就是说，让我们勾勒出你的问题。
DeveloperA已经创建了特定于任务的分支，例如来自Master的taskA。他多次致力于taskA分支。
A - B [master]
\
C - D [taskA]
平均而其他developerB从Master创建了他的分支taskB，并对taskB进行了多次更改，并将taskB合并为Master。
F - G
/ \
A - B - E ----- H [master]
\
C - D [taskA]
DeveloperA将Master合并到taskA分支并继续执行任务，并对taskA分支进行更多更改！
F - G
/ \
A - B - E ----- H [master]
\ \
C - D ----- I - J - K [taskA]
最终他会将taskA分支合并为Master。
F - G
/ \
A - B - E ----- H --------- L [master]
\ \ /
C - D ----- I - J - K
现在我只想将taskA分支合并到Release分支，但是当taskA在第4步中将Master合并到他的分支中时，taskB也被合并到taskA分支中，我将taskB分支自动更改为Release分支！我不希望这样。
你有几个选择。您可以git cherry-pick只将taskA中的提交发布到Release中，避免合并提交。那是C，D，J和K.如果J或K依赖于来自taskB的任何东西（或Master中未发布的任何其他东西），你将会遇到冲突或（希望）测试失败。这是一个混乱的手动过程。
第二种选择，而不是功能分支使用合并来从Master获取更新，在主服务器之上使用rebase。当taskA的开发人员决定从master更新时，如果他们已经运行git rebase master而不是git merge master，那么他们就会有这个。
F - G
/ \
A - B - E ----- H [master]
\ \
C - D C1 - D1 [taskA]
C和D将被重新安装在master的新位置之上。开发人员必须处理任何冲突和测试问题。然后他们可以继续工作并在完成后合并为主人。
F - G
/ \
A - B - E ----- H ----------------- L [master]
\ \ /
C - D C1 - D1 - J1 - K1 [taskA]
这种方法使分支保持良好和干净，没有中间合并。您可以选择整个分支到Release而无需选择中间合并。如果taskA依赖于尚未合并到Release中的任何内容，您仍会遇到冲突和测试失败，但至少隔离该功能的过程更简单。
由于您的工作流程要求您将功能分支进行两次集成，并且可能采用不同的顺序，因此您可能会遇到冲突。如果他们只是必须再次无序地合并到Release中，那么将功能合并到Master中是没有意义的。
我强烈建议您更改流程，以便只需将功能分支一次集成到Master中。发布只是Master的早期版本。如果功能分支尚未准备好发布，不会将其合并。这是一般的良好开发实践，它提高了开发人员正在使用的代码的质量（即Master），并且它避免了开发人员必须处理不稳定的一半完成的功能。
有时您会想要将修补程序应用于Release，这没关系。并且有时你会想要从Master中删除一个功能，这也很好。这些应该是特殊的任务，而不是正常的工作流程。