背景： 当我加入这家公司时，该公司使用GitHub作为其源代码控制。所有开发都在“ develop”分支上完成，我甚至不确定“ master”分支是否正式存在。加入后不久，我们切换到了VSTS（现在称为Azure DevOps）Git。我们创建了一个新的Repo，并将远程控制从GitHub更改为新的Git Repo，并推动了开发。太好了，我们得到了所有的历史和源代码。新的VSTS Git存储库具有一个“主”分支，但与我们的“开发”分支完全无关。
现在： 我们的开发经理离开了，他也离开了对单个分支进行开发的要求（救济）。但是现在我被困住了。目标是像nvie这样的策略。我曾尝试将PR'ing合并为“ master”，但这总是会导致合并冲突，而无法通过将master合并为dev再进行PR'ing（如我所习惯的）来解决。我怀疑这是因为未将“ develop”创建为“ master”的分支。我该如何追溯解决此问题？我想保留所有开发提交历史记录。
我当时正在考虑重命名development-> master，然后创建一个新的master，但这会中断所有尚未PR的功能分支吗？
答案 0 :(得分：0)
您可能想研究其他merge strategies of git。
有一种ours策略-git merge -S ours develop-将合并到开发分支中，而忽略develop分支中的所有更改。因此将以一个看起来像以前但从现在开始的分支develop的真正后代结束，从而允许进一步的合并以仅引入第一次合并之后提交的新更改。