我试图合并两个分支机构,这就是我所做的和发生的事情:
Abdulla (Master) new-git-project1
$ git merge sidebar
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
Abdulla (Master *+|MERGING) new-git-project1
$ git merge sidebar
error: Merging is not possible because you have unmerged files.
hint: Fix them up in the work tree, and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit.
fatal: Exiting because of an unresolved conflict.
我是新手,所以我可以得到简单的答案。
答案 0 :(得分:3)
您遇到了合并冲突。这意味着Git无法自动确定如何合并这两个分支。 Git要求您手动进行合并,并通过告诉您哪些文件无法自动合并,以及它们遇到问题的这些文件中的具体更改,为您提供一些帮助。
运行git status
。它将输出未合并的文件列表。这些文件将包含与此类似的冲突标记:
foo
<<<<<<< HEAD
BAR
=======
bar baz
>>>>>>> foo
qux
这意味着HEAD
(或者您当前所在的提交或分支)已将行更改为BAR
,并且分支foo
已将同一行更改为{{ 1}}。
根据自己的喜好编辑每个冲突,确保不再有冲突标记。例如,如果您更喜欢上面示例中的bar baz
版本,则只需编辑该文件即可:
BAR
保存每个文件并随时添加。
foo
BAR
qux
有些工具可以为您执行文件编辑部分,有些人发现它们比手动编辑文件更容易使用。
完成后,运行# (edit <file>)
git add <file>
以确保您没有更多未合并的文件。然后,如果您对结果感到满意,请运行git status
以完成合并。
Git - Basic Branching and Merging提供了有关合并冲突的更多信息。
另一种常用的方法是首先将另一个分支(在这种情况下为git commit
)重新绑定到要合并的分支的顶部(在这种情况下为sidebar
):
master
您可能仍会遇到冲突,但在这里修复它们有时会更容易。过程与上述过程相同,编辑文件,添加文件,提交。完成后,运行git checkout sidebar
git rebase master
以继续rebase过程。
然后,最后你可以合并分支而不会发生冲突:
git rebase --continue
git checkout master
git merge --no-ff sidebar
是可选的;有了它你会得到一个合并提交来表示你合并了一个分支,没有它你的历史将是线性的没有合并提交。
在合并之前进行重新定位的好处是在实际合并中永远不会出现合并冲突,这意味着合并提交永远不会引入除正在合并的分支中的提交已经引入的更改。这使历史更容易理解。
重新定位的缺点是提交应用于代码的新状态之上。这暗示您需要检查每个提交以确保它仍然正确。为了避免将来出现意外,花一点时间做这个是个好主意。
* 在重新定义具有合并的分支时,请避免或至少使用谨慎。 Rebase吃掉了合并。避免重新定义另一个人的提交也是一个好主意。变更的作者通常是最了解如何正确解决由此引起的任何合并冲突的人,因此如果可能,最好委托冲突解决。
答案 1 :(得分:0)
此消息表示两个分支上的index.html中存在一些不相同的更改。因此存在合并冲突。所以你必须使用像meld这样的mergeto来解决这些冲突。在这里,你必须决定你必须在这个分支上保留哪些变化。解决这些冲突后,您必须提交本地更改,然后将其推送到远程git存储库。您可以参考下面的链接来解决冲突。 https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/