大约一年前，我从master分支了，该分支变成了一个长期运行的第二个项目。在这段时间内，相同的文件在每个分支中都进行了近乎完全的重写。现在，我已经将分支中的代码库移到了自己的文件夹中，但是合并后，两个单独的项目共同使用的文件会发生一年的冲突。
最好的方法是重写分支的整个历史记录以使用其他文件夹吗？如何将这两个代码库合并到单独的文件夹中？
答案 0 :(得分：0)
最好的方法是重写分支的整个历史记录以使用其他文件夹吗？
这取决于它们在逻辑上是否是不同的文件。如果从逻辑上讲它们是单个文件-如果一个项目的更改在最坏的情况下不会损害其他项目的使用，尤其是如果相同的更改通常使两个项目都受益，则最好从维护角度考虑合并它们。但是，如果单个文件不再同时服务于两个母版，那么您就必须拆分它们-无论是通过简单地重命名/移动上面提到的母版，还是通过更复杂的重构（如果有原因）（例如，文件的某些部分）仍然很常见）。
这是您必须确定的事情。如果您确实希望将它们分开，则可以重写一个项目的历史记录来重新定位文件。从概念上讲它很简单，所以这是加号。不利的一面是，它可能会破坏该项目的历史版本（因为它可能会在另一个项目的文件中找到其期望的文件位置...除非您进行更彻底的重写以将每个历史版本更新为知道文件已移动），如果共享了回购协议，则所有用户都必须协调以更新到新的历史记录。
现在，如果整个项目的代码是如此无关紧要，以至于只将每个代码库放在一个单独的文件夹中就有意义了，那么您可能要考虑将它们保存在单独的存储库中。出于某种原因，“ monorepos”获得了一些普及，但实际上这并不是git的最佳用法。为了使用该工具的术语，您应该让每个仓库都是一个项目的所在地（并且，如果有共享的组件，最好将其移至第三个仓库，并使用git子模块或构建工具将其包含为每个项目的依赖项）项目）。
但是，如果您仍然决定要让两个项目共享一个历史记录，并在共享提交中共存于不同的文件夹中，则有两种解决方法。
您注意到，您可以尝试重写分支的历史记录。我不确定这是否可以解决问题，因为在创建分支之前存在的所有这些文件中的任何一个在分支的第一次提交中仍会被视为“已移动”。 （除非您也将其移动到分支创建之前的共享历史记录中，否则在 other 分支的下一次提交中它将被视为“移回” ...）
因此，您可能只想调整合并的工作方式。在将文件移动到它们各自分支的末尾的将来路径之后，您可以启动合并，但不要提交；使工作树进入所需状态；然后提交。
假设确实有一些文件要合并，则可以正常启动合并，因为冲突会阻止提交。然后，作为“冲突解决”的一部分，您将整理出路径。
git checkout HEAD -- project-1-path
git checkout project-2-branch -- project-2-path
（其中project-1-path和project-2-path是您将有问题的文件的相应版本移动到的文件位置，在合并之前最后一次提交到每个分支的位置）。