问您打算如何合并多个分支？

EN

如果希望顺利合并，则应确保将每个合并的基本版本包含到版本控制系统中(如果有这些版本的话)。只要确定人们最常使用的分支之一是主干，那么每次有人从树干上分支时，您都需要在主干上记录一个版本，如果您有这些分支的话。没有那些基本版本，合并就会变得一团糟。

如果没有版本控制，甚至没有人在合并时执行代码的tarball，那么即使是基本版本，您也不能进行重构，因此需要非常小心。在合并任何东西之前，将代码放入源代码控制中。试着以尽可能近似的方式重建从哪里分支出来的分支。

现在，如果您的源代码管理系统记录了分支之间的合并链接，并且很好地跟踪了基本版本和合并(例如ClearCase )，那么您希望从较小的合并开始，这可以由单个开发人员完成，以便首先减少并行工作。然后与所有参与的开发人员进行大规模合并。

另一方面，如果您没有很好的跟踪，那么在随后的合并中，已经完成的合并的更改将再次弹出，您可能需要重新决定冲突。这是相当痛苦的，所以我建议大合并与完整的团队，这样每个人都可以看到什么已经决定，然后他们可以保留正确的代码，在他们的小合并。

主要的一点是，如果没有正确的合并跟踪，您对了解代码的人的需求就会增加，因为他需要识别进入文件的正确(当前)代码块。

我猜想每个子项目都有大量的副本/压缩文件，但是不同的“分支”存在于不同的文件夹/计算机中，或者通过其他方式进行区分。

然后有两个选项:要么重建整个项目历史，要么使用当前版本作为不同的合并基。

历史重构

只在以后需要完整的历史记录时才走这条路，因为这是一项很大的工作。

第一个问题是识别相互复制的版本。您可以使用文件时间戳来获得粗略的历史估计(在每个副本中查找最新的文件)。在您有了一个时间线之后，您可以将它们导入到一个VCS中，并查看是否出现了反向补丁(某些内容包含在rev4中，排除在rev5中，再次包含在rev6中)，这表明顺序不正确。另外，看看这些更改是否最有意义(更改创建了更多的特性和较小的bug)。在您得到正确的顺序之前，请准备多次执行此步骤。因此，不要为此使用最终的VCS，因为您可能希望抛出中间步骤。我还建议将存储库放在本地机器上，因为您需要在多个版本之间执行许多不同的操作，并且不需要任何网络延迟(我使用mercurial和tortoiseHg来执行此类任务)。

在此过程结束时，您应该按时间顺序拥有所有副本，并且知道(至少大致上)不同分支的基础。

所以当你有这样的事情时：

Base --> A --> A'
         \
          \---> B --> B'
                \
                 \--> C

您可以从创建带有Base的主干开始，在那里添加更改A和A‘。然后创建以A为父级的分支B，并添加B‘。然后创建以B为父级的分支C。你的每一份拷贝都是如此。

有了重建历史之后，就可以开始大合并了。但是，除非你能在重建的过程中重建内部合并，否则当你把一切都整合在一起的时候，你就不会有任何优势。

只有释放

将基本版本导入到VCS中。然后为其他版本创建一个分支，并将彼此的发布放到相应的分支中。然后你可以合并所有的东西。

在开始合并之前，我应该考虑使用什么样的版本控制工具(您没有提到正在使用的是什么)。绝对避免VSS，CVS和Perforce。Subversion和Perforce是可以的，但是如果您创建了许多分支，那么您会发现有一个管理开销来保持所有的工作。GIT、Accurev和PureCM是我用于合并的最好工具。如果您喜欢分布式模型，可以使用GIT，否则我将使用非常便宜的PureCM。

您应该根据通用代码为主干创建分支。由此，您可以从树干逐个创建其他分支。为项目分支创建一个工作区，将工作区文件与项目文件一起关闭并签入。然后，您可以将此更改合并回主干并解决任何冲突。