git 发生冲突时如何强制合并成功?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/36820084/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How to force a merge to succeed when there are conflicts?
提问by jww
I'm trying to merge a pull request that has one conflict in one file (see below). The instructions for merging the pull request are provided by githubare as follows. Its important to to perform this merge so the person submitting the pr gets credit for it.
我正在尝试合并一个在一个文件中有一个冲突的拉取请求(见下文)。合并拉取请求的说明由github提供如下。执行此合并很重要,因此提交公关的人会因此而受到赞扬。
# Step 1: From your project repository, check out a new branch and test the changes.
git checkout -b droark-master master
git pull https://github.com/droark/cryptopp.git master
# Step 2: Merge the changes and update on GitHub.
git checkout master
git merge --no-ff droark-master
git push origin master
I know how to fix the one line in the one conflicting file. What I don't know how to do is make Git perform the merge and stop complaining about broken index files.
我知道如何修复一个冲突文件中的一行。我不知道该怎么做是让 Git 执行合并并停止抱怨损坏的索引文件。
How do I make Git perform the merge, ensure the person who provided the pull request gets credit for it, and stop breaking index files?
我如何让 Git 执行合并,确保提供拉取请求的人为此获得荣誉,并停止破坏索引文件?
I tried to repair the merge with Git merge errors. One set of errors turns into another set of errors, ad infinitum. I also tried resetting the problem file according to Ignore files during mergewith plans to copy/paste the one line needed, but the broken index persists.
我试图用Git 合并错误修复合并。一组错误会变成另一组错误,无穷无尽。我还尝试在合并期间根据忽略文件重置问题文件,并计划复制/粘贴所需的一行,但损坏的索引仍然存在。
This has turned into a complete waste of time, and I am no longer interested in trying to do it Git's way since it wastes so much time. Now I simply want Git to perform the merge and stop breaking index files.
这完全是浪费时间,我不再有兴趣尝试以 Git 的方式来做,因为它浪费了太多时间。现在我只想让 Git 执行合并并停止破坏索引文件。
Here is the output produced when merging using github's instructions:
以下是使用 github 的说明进行合并时产生的输出:
$ git pull https://github.com/droark/cryptopp.git master
From https://github.com/droark/cryptopp
* branch master -> FETCH_HEAD
Auto-merging validate.h
Auto-merging validat2.cpp
Auto-merging validat1.cpp
Auto-merging test.cpp
CONFLICT (content): Merge conflict in test.cpp
Auto-merging pubkey.h
Automatic merge failed; fix conflicts and then commit the result.
回答by Anthony E
There's no way to merge without resolving conflicts. Otherwise, how would git know what to merge? You can, however, checkout the version from either branch you're merging using git checkout --ours <filepath>
or git checkout --theirs <filepath>
. Here's an example:
不解决冲突就无法合并。否则,git 怎么知道要合并什么?但是,您可以使用git checkout --ours <filepath>
或 来从要合并的分支中检出版本git checkout --theirs <filepath>
。下面是一个例子:
Suppose you're on the master branch merging in staging:
假设您在合并暂存的 master 分支上:
git checkout master
git merge staging
And git shows a bunch of conflicts:
并且 git 显示了一堆冲突:
...
CONFLICT: Readme.md
...
If you want to keep the version of Readme.md
that's on master, then you would run:
如果您想保留Readme.md
master 上的版本,则可以运行:
git checkout --ours Readme.md
Note that since you're on master --ours
refers to "this" branch, i.e. master.
请注意,由于您在 master 上--ours
是指“这个”分支,即 master。
Now, you can simply add it to the index to mark it as resolved:
现在,您可以简单地将其添加到索引中以将其标记为已解决:
git add Readme.md
This effectively ignores any changes to Readme.md
on the staging
branch.
这有效地忽略了Readme.md
对staging
分支的任何更改。
You can repeat this process for each file you want to omit from the merge. When you're done, commit as you normally would:
您可以对要从合并中省略的每个文件重复此过程。完成后,像往常一样提交:
git commit -m "whatever..."
In order to repeat it for all files with conflicts you can do
为了对所有有冲突的文件重复它,你可以这样做
for f in $(git diff --name-only --diff-filter=U | cat); do
echo "Resolve conflict in $f ..."
git checkout --theirs $f
done
回答by ivan_pozdeev
There's no way around resolving conflicts, that's how revision control works (if Alice says "a" and Bob says "b", how should Git know which one is correct unless youtell it?). All you can do is direct git
to resolve them itself when merging in one of several possible ways, e.g.
没有办法解决冲突,这就是版本控制的工作原理(如果 Alice 说“a”而 Bob 说“b”,Git 怎么知道哪个是正确的,除非你告诉它?)。您所能做的就是git
在以几种可能的方式之一合并时直接自行解决它们,例如
git merge -s recursive -X theirs <branch>
(-s recursive
is the default when there's only one <branch>
so you can omit it here)
(-s recursive
当只有一个时是默认值,<branch>
因此您可以在此处省略它)
Now that you already have a conflict in your tree, you either
既然您的树中已经存在冲突,您要么
- follow the manual resolution route
- edit the file to your heart's desire
git add
it (add
in Git doubles as marking a file resolved)git commit
to complete the merge; or
- restore the pre-merge state with
git merge --abort
and retry the merge with the above-mentioned auto-resolution options
- 遵循手动解决路线
- 根据您的意愿编辑文件
git add
它(add
在 Git 中兼作标记文件已解决)git commit
完成合并;或者
git merge --abort
使用上述自动分辨率选项恢复合并前状态并重试合并
回答by Schwern
Resolving a conflict is just like dealing with any other work in progress. All changes must be staged (git add
) and then committed. Files which have successfully auto merged are already staged. Conflicted files are not.
解决冲突就像处理任何其他正在进行的工作一样。所有更改都必须暂存 ( git add
) 然后提交。已成功自动合并的文件已暂存。冲突文件不是。
Edit the conflicted files to your satisfaction, stage them (git add
), and when that is all done, git commit
.
编辑您满意的冲突文件,将它们暂存 ( git add
),完成后,git commit
.
In your case specifically...
在你的情况下特别...
- Edit
test.cpp
to fix the conflicts (they have<<<<
markers) git add test.cpp
- Run your tests to make sure everything is ok.
git commit
- 编辑
test.cpp
以修复冲突(它们有<<<<
标记) git add test.cpp
- 运行您的测试以确保一切正常。
git commit
回答by ShadowCore
Push development into master
推开发为主
git push --force origin branchA:branchB
This will force a merge and then push
这将强制合并然后推送
回答by john
If you know the changes in the current working branch is what you want, you can simply add ours
flag to a git merge.
如果您知道当前工作分支中的更改是您想要的,您可以简单地将ours
标志添加到 git merge。
git merge -s ours master
This effectively ignores all other branch changes and guarantees the merge output is that of the current working branch.
这有效地忽略了所有其他分支更改并保证合并输出是当前工作分支的输出。
More info and strategies here : https://www.atlassian.com/git/tutorials/using-branches/merge-strategy
更多信息和策略在这里:https: //www.atlassian.com/git/tutorials/using-branches/merge-strategy