保存在git分支上的新代码，如何将其合并回trunk

Question

序列：

1. 在trunk上提交一些代码
2. 发现它有一个令人讨厌的问题。
3. 制作分支
4. 删除主干上的代码（删除整个文件）
5. 修复分支上的代码

现在我想把整个业务带回主干。我认为合并不会这样做。会是什么？

Answer 1

假设这里没有git-svn疯狂（我不确定你使用“trunk”这个词是否意味着你来自svn并保留术语，或者实际上是与它进行交互）...

最简洁的方法是，假设你的“在主干上删除代码”分类步骤是在一个单独的提交中完成的，是恢复该提交，然后合并：

git checkout master
git revert <triage-commit>     # could do this for multiple commits if needed
git merge bugfix-branch

如果不是那么干净，合并就是要走的路;你只需处理一些事情。您可能希望在测试分支上进行以防万一：

# start back from master
git checkout -b master-merge master
# merge your fixes
git merge bugfix-branch

此时，你应该遇到很多“被我们删除”的冲突（这就是git status报告它们的方式）。这表明它们已在“我们的”分支（主）上删除，但在要合并的分支上进行了修改。它将保留树中待合并分支的版本。您可以git add将它们标记为已解决。如果您有不是此表单的冲突，则必须像往常一样处理它们。修好后，检查结果，测试并git commit完成合并。

如果您确信所有冲突都会来自此分类/错误修正方案，那么您可以使用git merge -X theirs告诉Git通过保留“他们的”版本（来自bugfix分支的那个）来解决所有冲突）。只有在你确定的情况下才能这样做！

git-svn注意：我听说git-svn存在合并问题。我从来没有使用它，我不知道它是如何工作的，但是如果是你不应该合并任何你打算发送回svn repo的情况...那么你不是在上面合并，而是可以改变git rebase master bugfix-branch。您将遇到完全相同的合并冲突。处理完毕后，您可以使用git checkout master; git merge bugfix-branch快速转发到新移植的分支。

Answer 2

在git中，如果尚未推送更改，则可以使用rebase。 （并且你通常在提交之前进行分支，在委托之前先进行测试：1。制作分支，2。提交，3。测试，4。推送，5。让其他人测试，6。如果看起来没问题就合并到主人所有人。）