避免将master合并到开发分支 [英] Avoid merging master into development branch

问题描述

我一直在监视从每个冲刺开始的两个分支-Release和Master.

I have been monitoring two branches starting from each sprint - Release and Master.

Master分支是开发人员从中创建新分支(特定于任务)，实施更改并创建合并到Master中的拉取请求的地方.

Master branch is from where developers create new branch(task specific), implement their changes, and creates pull request which gets merged into the Master.

Release分支是特定于Sprint的，始终始终可提交给生产.我们仅将提交给Master并由质量检查人员验证的分支合并到Release分支中.

Release branch is sprint specific which remains always submittable to the production. We only merge branches committed to the Master and verified by the QA into Release branch.

这种方法最适合我们，因为我们以固定的时间间隔提交了Release，其中已实现并验证了特定功能，因此我们完全知道下一版本的内容.

This approach works best for us as we submit Release at fix regular interval with specific functionality implemented and verified, and hence we exactly know what's going in the next release.

这很好，直到我遇到以下问题；

It's going great until I ran into following issue;

1. DeveloperA已从Master创建了特定于任务的分支，例如taskA.
2. 他多次向taskA分支机构承诺.
3. 表示其他开发者B从Master创建分支taskB，并对taskB提交了多个更改，并将taskB合并到Master中.
4. DeveloperA将Master合并到taskA分支中并进一步执行其任务，并将更多更改提交到taskA分支中！
5. 最终，他将把taskA分支合并到Master.

1. DeveloperA has created task specific branch say taskA from Master.
2. He has committed multiple times to taskA branch.
3. Mean while other developerB created his branch taskB from Master and committed multiple changes to the taskB and got taskB merged into Master.
4. DeveloperA will merge Master into taskA branch and further carry on his task, and commits more changes into taskA branch!
5. Eventually he will get taskA branch merged into Master.

现在，我只想将taskA分支合并到Release分支，但是随着taskB也被合并到taskA分支中，因为DeveloperA在步骤#4中将Master合并到了他的分支中，我得到了taskB分支自动更改为Release分支！我不要

Now I just want to merge taskA branch to Release branch but as taskB was also merged into taskA branch as DeveloperA merged Master into his branch in step#4, I get taskB branch changes automatically into Release branch! I don't want that.

避免合并Master到Developer分支的最佳方法是什么?在我的情况下，应该遵循的正确方法是什么?

What is the best way to avoid merging Master into Developer branch and what could be the right approach to follow in my case?

推荐答案

我认为您的策略过于复杂，容易出现问题.复杂的情况是试图将功能分支分别集成到Release和Master中.由于功能是在Master上开发的，因此每个功能分支都将利用较早的功能和错误修复.当您尝试将功能分支单独合并到Release中时，Release可能没有集成它所依赖的早期功能和错误修复.问题，冲突，并发症.

I think your strategy is too complicated and prone to problems. The complication is trying to integrate feature branches separately into both Release and Master. Because features are developed on Master, each feature branch is going to make use of earlier features and bug fixes. When you try to merge a feature branch separately into Release, Release might not have integrated the earlier features and bug fixes that it relies on. Problems, conflicts, complications.

如果您将功能分支从Master分支出来，将它们合并到Master，然后定期将Master合并到Release，则要简单得多.合并流程为功能->主文件->发布.从不提供功能->发布.实际上，应该有中间的Testing and Staging分支来保存当前在最终用户测试中的发行版(这是功能分支单元测试的基础)，以及为下一个发行版准备的内容.功能->主站->测试->分期->发布.

It is much simpler if you make feature branches off of Master, merge them into Master, and periodically merge Master into Release. The merge flow is Features -> Master -> Release. Never Features -> Release. In reality there should be intermediate Testing and Staging branches to hold the release currently in final user testing (this is on top of feature branch unit testing), and what is ready for the next release. Features -> Master -> Testing -> Staging -> Release.

也就是说，让我们找出问题所在.

That said, let's graph out your problem.

DeveloperA已从Master创建了特定于任务的分支，即taskA.他已经多次提交taskA分支.

DeveloperA has created task specific branch say taskA from Master. He has committed multiple times to taskA branch.

A - B [master]
     \
      C - D [taskA]

意味着其他开发者B从Master创建了他的分支taskB，并对TaskB进行了多次更改，并将taskB合并到Master中.

Mean while other developerB created his branch taskB from Master and committed multiple changes to the taskB and got taskB merged into Master.

          F - G    
         /     \
A - B - E ----- H [master]
     \
      C - D [taskA]

DeveloperA将把Master合并到taskA分支中，并进一步执行他的任务，并将更多更改提交到taskA分支中！

DeveloperA will merge Master into taskA branch and further carry on his task, and commits more changes into taskA branch!

          F - G    
         /     \
A - B - E ----- H [master]
     \           \
      C - D ----- I - J - K [taskA]

最终他将把taskA分支合并到Master中.

Eventually he will get taskA branch merged into Master.

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

现在，我只想将taskA分支合并到Release分支，但是由于在步骤#4中DeveloperA将Master合并到他的分支中，而taskB也被合并到taskA分支中，所以我将taskB分支自动更改为Release分支！我不要那个.

Now I just want to merge taskA branch to Release branch but as taskB was also merged into taskA branch as DeveloperA merged Master into his branch in step#4, I get taskB branch changes automatically into Release branch! I don't want that.

您有几种选择.您可以仅git cherry-pick将taskA中的提交提交到Release中，从而避免合并提交.那就是C，D，J和K.如果J或K依赖taskB中的任何内容(或Master中其他未发布的内容)，您将遇到冲突或(希望)测试失败.这是一个麻烦的手动过程.

You have a few choices. You can git cherry-pick only the commits in taskA into Release, avoiding the merge commits. That's C, D, J and K. If J or K relied on anything from taskB (or anything else in Master that isn't in Release) you'll get conflicts or (hopefully) test failures. This is a messy, manual process.

第二个选择，而不是使用合并功能从Master获取功能更新的要素分支，而是在master之上重新建立基础.当taskA的开发人员决定从master进行更新时，如果他们运行的是git rebase master而不是git merge master，那么他们将拥有此版本.

Second choice, instead of feature branches using merge to get updates from Master, rebase on top of master. When the developer of taskA decided to update from master, if they had ran git rebase master instead of git merge master, they'd have this.

          F - G    
         /     \
A - B - E ----- H [master]
     \           \
      C - D       C1 - D1 [taskA]

C和D将在新的主服务器位置上重新分配.开发人员必须处理任何冲突并测试问题.然后他们可以继续工作，并在完成后合并到母版中.

C and D would be repatched on top of the new location of master. The developer would have to deal with any conflicts and test problems. Then they could continue working and merge into master when they're done.

          F - G    
         /     \
A - B - E ----- H ----------------- L [master]
     \           \                 /
      C - D       C1 - D1 - J1 - K1 [taskA]

这种方法可以使分支保持良好且整洁，没有中间合并.您可以选择整个分支到Release，而不必选择中间合并.如果taskA依赖于尚未合并到Release中的任何内容，您仍然会有冲突和测试失败，但是至少隔离功能的过程更简单.

This approach keeps branches nice and clean with no intermediate merges. You can cherry pick the whole branch to Release without having to pick out the intermediate merges. You'll still have conflicts and test failures if taskA relies on anything which hasn't been merged into Release, but at least the process of isolating the feature is simpler.

因为您的工作流程要求您两次集成功能分支，并且顺序可能不同，所以可以确保存在冲突.如果仅需要将功能重新无序地合并到Release中，那么将功能合并到Master中实际上是没有意义的.

Because your workflow requires you integrate your feature branches twice, and in possibly different orders, you're guaranteed to have conflicts. There's really no point to merging features into Master if they're just going to have to be merged again out of order into Release.

我强烈建议您更改流程，以便您只需将一次功能分支集成到Master中.发布只是Master的早期版本.如果功能分支尚未准备好发布，请不要合并.通常，这是一种好的开发实践，它提高了开发人员正在使用的代码(即Master)的质量，并且避免了开发人员不得不处理不稳定的半成品功能.

I strongly encourage you to change your process so you only have to integrate feature branches once, into Master. Release becomes just an earlier version of Master. If a feature branch isn't ready for release, don't merge it. This is good development practice in general, it raises the quality of the code the developers are working with (ie. Master), and it avoids developers having to work on an unstable pile of half finished features.

您有时会希望对Release应用修补程序，这很好.有时您会想要从Master删除功能，这也很好.这些应该是特殊的任务，而不是正常的工作流程.

From time to time you will want to apply hot fixes to Release, that's fine. And from time to time you'll want to remove a feature from Master, and that's fine, too. These should be exceptional tasks, not normal workflow.

这篇关于避免将master合并到开发分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！