如何放弃远程更改并将文件标记为“已解决”？ [英] How can I discard remote changes and mark a file as "resolved"?
问题描述
我有一些本地文件，我从远程分支中拉出并且存在冲突。我知道我想保留本地更改并忽略导致冲突的远程更改。有没有一个命令我可以用来实际上说标记所有冲突解决，使用本地？
git checkout 有 - 我们的选项可以检出本地文件的版本（而不是 - 他们的，它是你拉进去）。您可以将。传递给 git checkout 来告诉它检查树中的所有内容。然后，您需要将冲突标记为已解决，您可以使用 git add ，并且完成一次完成工作：
git checkout --ours。 ＃checkout我们所有文件的本地版本
git add -u＃将所有冲突文件标记为合并
git commit＃提交合并
请注意 git checkout 命令中的。。这是非常重要的，容易错过。 git checkout 有两种模式;一个用于切换分支，另一个用于将文件从索引中检入到工作副本中（有时将其从另一个修订中首先拉入索引）。它的区别在于你是否通过了一个文件名;如果你没有传入文件名，它会尝试切换分支（尽管如果你没有传入分支，它只会尝试再次检出当前分支），但是如果有修改过的文件，它会拒绝这么做那会影响。因此，如果您想要覆盖现有文件的行为，您需要传入。或文件名以获取第二个行为 git checkout 。
当传入文件名时，使用来抵消它也是一个好习惯。 ，例如 git checkout --ours - < filename> 。如果你不这样做，并且文件名恰好匹配分支或标签的名称，Git会认为你想检查该修订版，而不是检查该文件名，所以使用第一种形式的 checkout 命令。
我将展开一些关于如何冲突和合并在Git中工作。当你在其他人的代码中合并时（这种情况也发生在拉取过程中;拉取本质上是一个获取，然后是合并），但是有几种可能的情况。
最简单的是，你在同一个版本上。在这种情况下，你已经是最新的，没有任何反应。
另一种可能性是他们的修改只是你的后代，在这种情况下，你默认情况下会有一个快进合并，其中你的 HEAD 只是更新到它们的提交，而没有合并发生（如果你真的想要使用 - no-ff ）记录合并。
然后，您将进入实际需要合并两个修订版的情况。在这种情况下，有两种可能的结果。一个是合并发生干净;所有更改都在不同的文件中，或者位于相同的文件中，但分开的距离足够远，以便两组更改都可以毫无问题地应用。默认情况下，当一个干净的合并发生时，它会自动提交，但是如果你需要事先编辑它，你可以用 --no-commit 禁用它（例如，if您将 foo 重命名为 bar ，并且其他人添加了调用 foo ，它会很干净地合并，但会产生一棵破碎的树，所以你可能想把它作为合并提交的一部分进行清理，以避免有任何破坏的提交。）
最后的可能性是存在真正的合并，并且存在冲突。在这种情况下，Git将尽其所能完成合并，并生成带有冲突标记的文件（<<<<<<<< ， ======= 和>>>>>>>< / code> ）在你的工作副本中。在索引（也称为暂存区域;在提交它们之前由 git add 存储文件的位置），每个文件都有3个版本存在冲突;有来自您正在合并的两个分支的祖先的文件的原始版本，来自 HEAD （您合并的一侧）的版本以及来自远程的版本分支。
为了解决冲突，您可以编辑工作副本中的文件，删除冲突标记并修复代码，使其可以工作。或者，您可以使用 git checkout --ours 或 git checkout - 他们的 git add 进行提交，然后您可以提交与 git commit 合并。
I have some local files, I pull from remote branch and there are conflicts. I know that I would like to keep my local changes and ignore the remote changes causing conflicts. Is there a command I can use to in effect say "mark all conflicts as resolved, use local"?
git checkout has the --ours option to check out the version of the file that you had locally (as opposed to --theirs, which is the version that you pulled in). You can pass . to git checkout to tell it to check out everything in the tree. Then you need to mark the conflicts as resolved, which you can do with git add, and commit your work once done:
git checkout --ours . # checkout our local version of all files
git add -u # mark all conflicted files as merged
git commit # commit the merge
Note the . in the git checkout command. That's very important, and easy to miss. git checkout has two modes; one in which it switches branches, and one in which it checks files out of the index into the working copy (sometimes pulling them into the index from another revision first). The way it distinguishes is by whether you've passed a filename in; if you haven't passed in a filename, it tries switching branches (though if you don't pass in a branch either, it will just try checking out the current branch again), but it refuses to do so if there are modified files that that would effect. So, if you want a behavior that will overwrite existing files, you need to pass in . or a filename in order to get the second behavior from git checkout.
It's also a good habit to have, when passing in a filename, to offset it with --, such as git checkout --ours -- <filename>. If you don't do this, and the filename happens to match the name of a branch or tag, Git will think that you want to check that revision out, instead of checking that filename out, and so use the first form of the checkout command.
I'll expand a bit on how conflicts and merging work in Git. When you merge in someone else's code (which also happens during a pull; a pull is essentially a fetch followed by a merge), there are few possible situations.
The simplest is that you're on the same revision. In this case, you're "already up to date", and nothing happens.
Another possibility is that their revision is simply a descendent of yours, in which case you will by default have a "fast-forward merge", in which your HEAD is just updated to their commit, with no merging happening (this can be disabled if you really want to record a merge, using --no-ff).
Then you get into the situations in which you actually need to merge two revisions. In this case, there are two possible outcomes. One is that the merge happens cleanly; all of the changes are in different files, or are in the same files but far enough apart that both sets of changes can be applied without problems. By default, when a clean merge happens, it is automatically committed, though you can disable this with --no-commit if you need to edit it beforehand (for instance, if you rename function foo to bar, and someone else adds new code that calls foo, it will merge cleanly, but produce a broken tree, so you may want to clean that up as part of the merge commit in order to avoid having any broken commits).
The final possibility is that there's a real merge, and there are conflicts. In this case, Git will do as much of the merge as it can, and produce files with conflict markers (<<<<<<<, =======, and >>>>>>>) in your working copy. In the index (also known as the "staging area"; the place where files are stored by git add before committing them), you will have 3 versions of each file with conflicts; there is the original version of the file from the ancestor of the two branches you are merging, the version from HEAD (your side of the merge), and the version from the remote branch.
In order to resolve the conflict, you can either edit the file that is in your working copy, removing the conflict markers and fixing the code up so that it works. Or, you can check out the version from one or the other sides of the merge, using git checkout --ours or git checkout --theirs. Once you have put the file into the state you want it, you indicate that you are done merging the file and it is ready to commit using git add, and then you can commit the merge with git commit.
这篇关于如何放弃远程更改并将文件标记为“已解决”？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
