我有一群开发人员使用分支进行错误修复。我的需求：自动化（或有没有办法）将所有这些分支合并到一个主分支“默认”的最佳方法是什么。
谢谢
问问题
161 次
1 回答
6
注意：这是我的意见，这里可以有多种意见，但至少在这里理解我的观点并决定你想要它不同。
首先，这里缺少一些东西，我认为从长远来看这会给您带来工作流程问题。
合并不是应该被跳过或委托给其他人的事情，在这些分支中工作的开发人员应该自己合并。他们，可能只有他们，会知道他们做了什么，以及如何解决合并冲突。
无论如何，完全自动化地做这件事是行不通的。
这是开发人员应该使用的工作流程（在我看来。）
定期，例如每天早上，分支上的开发人员应该检查构建服务器以确保默认分支构建。如果是（并且应该！），它们会从默认分支合并到自己的分支中。
这有三个主要好处：
- 他们总是在自己的分支中拥有最新的代码，并且不会陷入解决已经在另一个分支中修复的已知错误的困境
- 他们不断地处理来自其他分支的合并冲突，虽然冲突很小，但所做的开发人员对这些变化仍然记忆犹新。
- 由于您每天都在处理合并冲突（如果有的话），当您到达该分支的生命周期结束时，无论如何它几乎完全与默认分支合并，因此将其合并回默认分支所涉及的工作现在应该很便宜，如果不是免费的话。
在某些时候，他们被读取以将他们的工作整合回默认分支（定期，即新功能的部分发布，或者最后，一切都完成了），然后他们再次从默认合并回到他们的自己的分支。这确保了任何挥之不去的合并冲突都由该团队在其分支中处理，然后再将其发布给其他开发人员。
当他们处理了由于该合并导致的任何合并冲突时，他们可以合并另一个方向，从他们的分支回到默认值。此时，除非有人同时设法将任何有冲突的更改合并/推送到默认值，否则根本不会发生合并冲突。
这样做可以确保：
- 进行合并的开发人员接受合并培训
- 进行更改的开发人员仍然在记忆中保留这些更改
- 您可以通过经常执行合并冲突并分小部分执行来分摊与合并冲突有关的工作。
- 你不会在项目结束时获得一个大的合并——“一周”，那时每个人都忘记了所有的变化，为什么要完成以及是谁做的
如果其中任何一个不清楚，请发表评论，我会相应地更新/编辑。
于 2011-04-29T10:54:06.503 回答