我最近加入了一个代码库,该代码库尚未受版本控制.代码已经由组织中的不同人员多次分叉,从事不同的项目.现在我们将开始使用版本控制,我们希望合并来自不同项目的宝贵贡献.这些项目共享一个共同的原始版本,因此我为每个项目创建了一个分支,并计划开始合并.现在我想知道在合并时使用什么策略.

你会如何选择分支开始合并？变化最小的那个？那个最可怕的人？在将其中一个项目合并到主干后,您是否会将所有分支与主干同步？与许多分歧很多的分支机构合作时,是否有最好的做法？

或者我应该停止担心并开始逐一合并它们？

最佳答案 如果要进行平滑合并,则应确保在版本控制系统中包含每个合并的基本版本(如果有).只要确定人们最多分支的一个分支是一个主干,然后你需要在每次有人分支的时候在主干上记录一个版本,如果你有这些分支.没有这些基础版本,合并将变得一团糟.

如果没有版本控制,甚至没有人在他们合并时执行代码的tarball,所以你甚至不能像基本版本一样重建,你需要非常小心.在合并任何内容之前将代码放入源代码控制中.尝试通过从哪里分支的方式尽可能近似地重建分支.

现在,如果您的源代码控制系统记录分支之间的合并链接并保持基本版本和合并的良好跟踪,例如ClearCase,您希望从较小的合并开始,这可以由各个开发人员完成,以便首先并行地减少工作.然后与所有涉及的开发人员进行大型合并.

另一方面,如果您没有良好的跟踪,则在后续合并中将再次弹出已完成合并的更改,您可能需要再次重新更新冲突.这是非常痛苦所以我建议与整个团队进行大型合并,这样每个人都可以看到已经决定的内容,然后他们可以在较小的合并期间保留正确的代码.

重点是,如果没有适当的合并跟踪,您需要了解代码存在或进行合并的人,因为他需要识别正确的(当前)代码块以进入文件.