我继承了一个大型代码库，其中开发分支已经在git下使用了一段时间，但是生产还没有受到任何版本控制。
..我知道。
将代码升级到生产的方法是手动从开发和生产中来回复制所有已更改的文件，直到它们同步，并在周末尽快处理后续灾难。
我已经将生产置于git git init/add/commit的全新实例下，现在可以跟踪所有这些在生产中生效的修补程序，（因为我回到每个人的后面并每天进行检查点提交）。我已经设定了原产地＆＃39;在生产上与开发相同，因此生产现在是同一个存储库的一个单独的分支，没有共同的祖先。
我希望有一个真正的开发过程，这意味着我想将分支合并在一起。
此时值得一提的是，开发人员在开发和生产分支上都有进展，因为主要的开发人员喜欢在生产中修改生活。我相信我可以改变他的这种习惯，如果我可以提供另一种方法来修复另一个分支并将 合并到生产中。
但要做到这一点，我需要一个与生产共享共同祖先的分支。
..我该怎么办？我可以将生产合并到dev中，这会产生大量的冲突，我可以尝试手工解决（也就是mergetool），但这听起来像TON的工作。
还有更好的方法吗？
我还在学习成为一名git guru，我想完成这项工作，但是......最好的方法是什么？
答案 0 :(得分：1)
首先：对不起乔恩，这听起来像是一团糟。 ： - （
这是一种方法：
git master branch ： 这应该是当前的生产。 （容易）
修补程序分支，来自主： 这些应该是您描述的在生产上完成的修补程序（很容易，假设修复者实际上这样做了）
开发分支： 从master的分支开始。然后将文件/更改复制到此分支中，就像团队已经做的那样，无论如何都要将文件从开发转移到生产。只要将修补程序应用于master，就可以在master中合并。这将导致一个分支可以合并到主无冲突，但有一个大的差异，可以由整个团队审查。 （很难，但值得）
一旦您完成了这一步，您就可以开始使用更为标准的方法，例如git-flow。