Git 重基合并冲突

我分了一份 Gitthub 回购协议，然后开始做我的 Gitthub 回购协议。
我已经提出了拉请求，它已经完成。

在此之后，上游有一些更多的提交，所以现在我想重建基础，我想这就是我必须做的。
但是我得到了这些合并冲突:

First, rewinding head to replay your work on top of it...
Applying: Issue 135 homepage refresh
Using index info to reconstruct a base tree...
<stdin>:17: trailing whitespace.
%h4
warning: 1 line adds whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging app/views/layouts/application.html.haml
CONFLICT (content): Merge conflict in app/views/layouts/application.html.haml
Auto-merging app/views/home/index.html.haml
CONFLICT (content): Merge conflict in app/views/home/index.html.haml
Auto-merging app/views/home/_group_projects.html.haml
CONFLICT (content): Merge conflict in app/views/home/_group_projects.html.haml
Failed to merge in the changes.
Patch failed at 0001 Issue 135 homepage refresh


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".

我不知道怎么修，请帮帮我。

249107 次浏览
小开
最佳答案

重新定位可能会让人头疼。必须解决合并冲突并继续重新定基。例如，您可以使用合并工具(其差异取决于您的设置)

git mergetool

然后添加您的更改，然后继续

git rebase --continue

祝你好运

小开

注意: 使用 Git 2.14. x/2.15(Q32017) ，如果发生冲突，git rebase消息将更加清晰。

见 提交5fdacc1(2017年7月16日) by William Duclot (williamdclt)。
(由 朱尼奥 · C · 哈马诺 gitster于2017年8月11日在 犯罪合并)

rebase: 为没有经验的用户提供更清晰的解决信息

以前:

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

之后:

Resolve all conflicts manually,
mark them as resolved with git add/rm <conflicted_files>
then run "git rebase --continue".


You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".')

可以通过将错误消息寻址到这些 他们帮助: 没有经验和临时的 git 用户。
为此，确保这些消息中使用的术语能够被这部分用户理解，并指导他们解析 问题。

特别是，在 git rebase 期间应用补丁失败是很常见的 问题，可以非常不稳定的经验不足的用户。
引导他们解决冲突是很重要的 3个步骤的过程，因此复杂) ，并让他们放心，他们可以逃脱一个 他们无法处理的情况下“ --abort”。
这种提交通过详细说明解析过程和避免隐晦的 git 语言来回答这两个问题。

小开

如果有很多提交需要重新定基，其中一些提交会产生冲突，那真的很伤人。但我可以建议一个 不太为人所知的方法如何“压制所有的冲突”。

首先，签出临时分支并启动标准合并

git checkout -b temp
git merge origin/master

你必须解决冲突，但只能解决一次，而且只能解决真正的冲突。 然后阶段所有文件，并完成合并。

git commit -m "Merge branch 'origin/master' into 'temp'"

然后返回到您的分支(设置为 阿尔法)并启动 rebase，但自动解决任何冲突。

git checkout alpha
git rebase origin/master -X theirs

分支已经重新基础，但项目可能处于无效状态。没关系，我们还有最后一步。我们只需要恢复项目状态，所以它将是精确的分支’临时’。从技术上讲，我们只需要通过低级命令 基特承诺树复制它的 树(文件夹状态)。加上合并到当前分支刚刚创建的提交。

git merge --ff $(git commit-tree temp^{tree} -m "Fix after rebase" -p HEAD)

并删除临时分支

git branch -D temp

仅此而已，我们通过隐藏合并重建了基地。

我还写了一个脚本，这样就可以在一个对话框中完成，你可以找到它 给你。

小开

如果你不介意挤压成一个大提交，最简单的方法我这样做是 git reset --soft <rebase-target>从您当前的分支，然后 git commit。

例如，您在您的分支上，要重新基于的目标是 origin/master。 假设您没有未分阶段的/正在进行的更改:

# Merge and fix any conflicts from master
git merge origin/master
# Push your changes in case you mess up and want to start over from remote
git push
# Move HEAD to rebase target, leaving all your work staged
git reset --soft origin/master
# Commit staged changes as giant commit
git commit -m "feat(foo): new feature"
# Confirm your changes, run tests, etc. Then force push
git push -f

您不必担心重做合并冲突，因为您的分支和 rebase 目标之间的所有差异都被移动到临时区域，一切都准备好提交了。

小开

在一些过于复杂的情况下，与删除，重命名，改变文件可能的救命稻草可能是使用空“缓冲区”提交与所有文件删除。它本身提供了更多的灵活性，而且在空之后的下一次提交将变得更加可靠和快照相似。


提交答案