我最近加入了一个团队，其代码库不受版本控制。该代码已被组织中从事不同项目的不同人员多次 fork 。现在我们将开始使用版本控制，我们想要合并来自不同项目的有值(value)的贡献。这些项目共享一个共同的原始版本，因此我为每个项目创建了一个分支并计划开始合并。现在我想知道合并时使用什么策略。
您将如何选择分支开始合并？变化最小的那个？最可怕的那个？将其中一个项目合并到主干后，您会将所有分支与主干同步吗？与许多分歧很大的分支机构合作时，是否有最佳实践可以遵循？
还是我应该停止担心并开始将它们一一合并？
最佳答案
如果您想要顺利合并，您应该确保将每个合并的基本版本包含到版本控制系统中(如果有的话)。只需确定人们最多分支的分支之一是主干，然后每次有人从主干分支时，您都需要在主干上记录一个版本，如果有的话。如果没有这些基本版本，合并将变得一团糟。
如果没有版本控制，甚至在合并时没有人对代码进行 tarball，因此即使是基本版本也无法重建，则需要非常小心。在合并任何内容之前将代码放入源代码管理中。尝试根据从哪里分支的内容以尽可能近似的方式重建分支。
现在，如果您的源代码控制系统记录分支之间的合并链接并很好地跟踪基本版本和合并，例如 ClearCase，您希望从较小的合并开始，这可以由单个开发人员完成，以首先减少并行工作。然后与所有相关的开发人员进行大型合并。
另一方面，如果您没有良好的跟踪，则已完成合并的更改将在后续合并中再次弹出，您可能需要再次重新确定冲突。这是相当痛苦的，所以我建议与整个团队进行大型合并，这样每个人都可以看到已经决定的内容，然后他们可以在较小的合并期间保留正确的代码。
要点是，如果没有适当的合并跟踪，您对理解代码存在或执行合并的人的需求就会增加，因为他需要识别正确的(当前)代码块才能进入文件。
关于svn - 您如何计划合并多个分支机构？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3520233/