我继承了一个大型代码库，其中开发分支已经在 git 下工作了一段时间，但生产不受任何版本控制。
..我知道。
将代码提升到生产的方法是手动从 dev 和 prod 来回复制所有更改的文件，直到它们同步，并在周末尽快处理后续灾难。
从那以后，我将生产置于一个全新的 git git init/add/commit 实例下，现在可以跟踪所有这些在生产环境中实时发布的修补程序（因为我回到每个人身后并每天进行检查点提交）。 我将生产的"起源"设置为与开发相同，因此生产现在是同一存储库的一个单独分支，没有共同的祖先。
在这里有一个真正的开发过程，这意味着我想将分支合并在一起。
在这一点上值得一提的是，开发和生产分支的开发都在进行，因为首席开发人员喜欢在生产环境中实时修复内容。 我相信我可以改变他的这个习惯，如果我能提供将修复程序应用于另一个分支并将其合并到生产中的替代方案。
但要做到这一点，我需要一个与生产共享共同祖先的分支。
..我该怎么办？ 我可以将生产合并到dev中，这将产生大量冲突，我可以尝试手动解决（即mergetool），但这听起来像是大量的工作。
有没有更好的方法？
我还在学习成为一名git大师，我想完成这件事，但是......最好的方法是什么？
首先：对不起，乔恩，这听起来一团糟。
这里有一种方法：
git 主分支：这应该是当前的生产。（简单）
修补程序分支，来自主服务器：这些应该是您描述在生产环境中完成的修补程序（简单，假设进行修复的人实际上这样做）
发展分公司：从主节点的分支开始。然后将文件/更改复制到此分支中，就像团队已经所做的那样，无论如何都要将文件从开发转移到生产。每当修补程序应用于主服务器时，都会合并到主服务器中。这将导致一个分支可以合并到主节点中，但具有可以由整个团队查看的大差异。（辛苦，但值得）
一旦你完成了这个，你就可以开始遵循一个更标准的方法，如git-flow。