当我从我的队友那里引入更改时,我通常会使用rebase,并且经常会有冲突:
...
CONFLICT (content): Merge conflict in app/views/search/index.html.erb
Auto-merging public/stylesheets/application.css
CONFLICT (content): Merge conflict in public/stylesheets/application.css
Failed to merge in the changes.
Patch failed at 0001 organizing
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".因此,在打开每个有冲突的文件后,修复它,然后提交修复的文件:
~/Projects/myApp[956f6e1...]% git rebase --continue
You must edit all merge conflicts and then
mark them as resolved using git add我仍然得到相同的错误...
~/Projects/myApp[64b3779...]% git rebase --continue
Applying: organizing
No changes - did you forget to use 'git add'?
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".我一直有这个问题,但我猜我从来没有真正选择解决它,我总是我只是变得懒惰和git rebase --skip。
我如何真正以正确的方式解决冲突?
发布于 2010-09-01 00:53:01
所以在打开每个有冲突的文件后,修复它,然后提交修复的文件...
问题是你不应该commit修复。如果a.txt有合并冲突,那么您的shell日志应该如下所示:
$ vim a.txt # fix conflict
$ git add a.txt
$ # no commit between add and rebase!
$ git rebase --continue调用git rebase --continue将处理提交本身。
我不知道如何在你提交之前“回到”,当你正在进行rebase的时候。git reset --hard HEAD可能会做到这一点,但就个人而言,我觉得直接转到git rebase --abort并重新开始会更安全,而不是在中间提交。
发布于 2013-05-20 02:04:59
我同意Mark Rushakoff的观点,修复提交不应该包括提交它们。
至少还有另外一种方式,git会继续说“你必须编辑所有的合并冲突,然后使用git add将它们标记为已解决”,即使你已经这么做了。如果您从git版本控制中删除文件,但将未版本化的文件留在工作树中,然后尝试执行rebase,则可能会发生这种情况。
我能够解决这个问题,如下所示:
通过查看将我的未版本化文件移到我的git rebase --abort
git status
git svn rebase
希望这能有所帮助。
发布于 2014-05-12 05:40:52
当这发生在我身上,我设法解决它后,意识到我已经编辑(并添加到索引)在重新基址的文件,没有冲突的,我猜这可能是错误的。所以我先用了git checkout -- <filename-with-no-conflict>,然后用了git rebase --continue,它起作用了。
https://stackoverflow.com/questions/3611260
复制相似问题