Question

在我们的项目中，我们使用git，我们在新分支中发布的每个功能，在代码查看后，CTO将其重新绑定到开发分支。在我完成我的机票后，CTO说他不能改变我的变化bc发生了冲突。我在本地机器上复制了它：

git clone ...
cd project1
git checkout my-branch
git rebase develop
...
Auto-merging admin/contest.html
CONFLICT (content): Merge conflict in admin/contest.html
Failed to merge in the changes.
Patch failed at 0019 contest: admin, dashboard, /contest

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".

好的，我解决了这个冲突，而不是添加了这个文件，但是我不能继续使用rebase或者推送一些东西。解决此类冲突的最佳方法是什么？

更新

我做了 git rebase - 继续后得到了：

Applying: $0 in admin/contest dropdown
No changes - did you forget to use 'git add'?
If there is nothing left to stage, chances are that something else
already introduced the same changes; you might want to skip this patch.

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".

Answer 1

无论是否互动，都可以通过重复一个简单的挑选过程来实现。

首先让我们定义一个“樱桃选择”。

假设您有一个分支（例如，生产分支），一般不准备升级，但您也有一个错误。进一步假设，在开发分支上，某人已经修复了该特定错误，并且修复程序简单而干净，并且可以在生产代码中使用。（例如，更改fileA中的一行和fileB中的两行可以解决问题，这可以在生产分支上完成。）

你可以：

$ git show 15fd3dc > /tmp/bug-fix

查看更改并将修补程序写入文件，然后手动复制修补程序git add和git commit。或者您甚至可以执行上述操作，或使用git format-patch，然后使用git apply或git am将修补程序导入分支production。但它更容易：你可以简单地使用分支production并使用：

$ git cherry-pick 15fd3dc

实际上，

和git将自动提取修复并应用和提交它。换句话说，它复制提交。

现在让我们考虑rebase。在这里我们有这样的事情：

... o - o - o - * - * - X - * - *   <-- your-work
              \
                o - Y - Z   <-- their-work

我已将其中一个提交X及其中两个提交标记为Y和Z，这样我就可以在以后对其进行特殊处理。首先让我们看一下rebase的机制。

要进行rebase，git只需要提交每个提交（*提交，以及中间的X）并将它们挑选到{{1}的末尾。 }。也就是说，我们创建一个新的临时分支并开始复制提交：

their-work

在许多情况下，所有提交都是轻率复制的：没有冲突，所有提交都是干净利落的。在这种情况下，git然后执行最后一步：擦除旧的分支标签... o - o - o - * - * - X - * - * <-- your-work \ o - Y - Z <-- their-work \ * - * <-- temp-branch，并将分支标签your-work更改为temp-branch，以便您的（复制的）提交现在位于提交之上your-work。

然而，在这种情况下，尝试挑选提交Z时存在冲突。它与提交X和Y中的一个或两个冲突：其他两个提交在Z中的更改所在的同一区域中发生了变化。

这是rebase停止的地方，并为您提供您看到的消息：

您可以通过编辑冲突文件（使用合并工具而不是纯文本编辑器，但效果相同）开始手动解析，并When you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To check out the original branch and stop rebasing run "git rebase --abort".最终文件。

接下来，您运行git add。此时有两种可能性（假设您根据需要记住git rebase --continue个文件）：

如果这是第一个被复制的提交，或者如果稍后提交git add提交的一个副本，那么您仍然可以对先前的修订版本Z进行一些更改;给出我在哪里提交{{1这将是其中一个副本）。
您实际上已在冲突解决期间删除了所有更改。也许提交*只有你所做的一半，然后提交X剩下的，所以现在你的提交Y对这两个提交是多余的。

您似乎遇到了案例（2）。在情况（1）中，Z继续复制剩余的X提交，然后移动您的分支标签。但是，在第（2）例中，git rebase --continue抱怨：

在这种情况下（如果你没有那么忘记执行git rebase --continue步骤），你应该如下一位告诉你的那样使用 No changes - did you forget to use 'git add'? If there is nothing left to stage, chances are that something else already introduced the same changes; you might want to skip this patch.。这告诉git完全忘记你之前的提交git add，然后继续挑选剩余的git rebase --skip提交。

如何在rebase之后修复冲突并推送它们

1 个答案: