git合并使用共享文件重写的分支

大约一年前，我从master分支，分支变成了一个长期运行的第二个项目。在此期间，相同的文件在每个分支中都经历了几乎完全的重写。我现在已经将分支中的代码库移动到了它自己的文件夹中，但是在合并之后，两个单独的项目联合使用的文件会有一年的冲突

重写我的分支的整个历史以使用不同的文件夹是最好的解决方案吗？如何将这两个代码基合并到单独的文件夹中

重写我的分支的整个历史以使用不同的文件夹是最好的解决方案吗

这取决于此时它们是否是逻辑上不同的文件。如果它们在逻辑上是一个文件——如果一个项目的更改在最坏的情况下不会影响另一个项目的使用，特别是如果相同的更改通常对两个项目都有利——那么最好在维护方面合并它们。但是，如果一个文件不再服务于两个主控器，那么您就必须将它们拆分——无论是简单地通过上面提到的重命名/移动一个，还是通过一个更复杂的重构（如果有一个原因（例如文件的某些部分仍然是通用的））。 所以这是你必须确定的。如果确实希望将它们分开，则可以选择重写一个项目的历史记录以重新定位文件。这在概念上很简单，所以这就是优点。缺点是，它可能会破坏项目的历史版本（因为它可能会在需要它的文件的地方找到另一个项目的文件…除非您进行更彻底的重写，更新每个历史版本以知道文件已移动），如果回购协议是共享的，那么所有用户都必须协调以更新新的历史记录

现在，如果项目的代码作为一个整体是不相关的，那么将每个代码库放在一个单独的文件夹中是有意义的，那么您可能需要考虑将它们保持在单独的RePOS中。出于某种原因，“monorepos”已经获得了一些流行，但实际上它并不是git的最佳用途。为了按照工具的条款工作，您可以让每个repo成为一个项目的家（如果有共享组件，理想情况下，将其移动到第三个repo，并使用git子模块或构建工具将其作为每个项目的依赖项）

但是，如果您决定继续让这两个项目共享一个历史记录，并在共享提交中的不同文件夹中共存，那么有几种方法可以实现

正如您所注意到的，您可以尝试重写分支的历史记录。我不确定这是否能解决问题，因为在创建分支之前存在的任何文件在分支的第一次提交中仍将被视为“已移动”。（除非在创建分支之前的共享历史记录中也移动它，在这种情况下，它将在另一个分支的下一次提交中被视为“向后移动”）

因此，您可能只想调整合并的工作方式。将文件移动到其各自分支尖端的未来路径后，您将启动合并，但不进行提交；使工作树进入所需状态；然后提交

假设您确实打算合并某些文件，则可以正常启动合并，因为冲突将阻止提交。然后，作为“冲突解决”的一部分，您将理清路径

git checkout HEAD -- project-1-path
git checkout project-2-branch -- project-2-path

---

（其中，

project-1-path

和

project-2-path

是您在合并前的最后一次提交到每个分支时将相关文件的各个版本移动到的文件位置）。

如果这两个项目发生分歧，是否有任何理由现在不完全分叉？代码库有前端和后端。前端冲突，我正在采用主分支的较新后端。因此，在项目的其他部分仍然存在大量的代码重用。在这种情况下，对项目1前端进行回购、对项目2前端进行回购和对共享后端进行回购可能会使您的生活更轻松。