如何放弃远程更改并将文件标记为“已解决"? [英] How can I discard remote changes and mark a file as "resolved"?

问题描述

我有一些本地文件，我从远程分支拉取并且存在冲突.我知道我想保留我的本地更改并忽略导致冲突的远程更改.是否有一个命令我可以用来实际上说将所有冲突标记为已解决，使用本地"?

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 有 --ours 选项来检查您在本地拥有的文件的版本(而不是 --theirs，这是您拉入的版本).您可以将 . 传递给 git checkout 以告诉它检查树中的所有内容.然后您需要将冲突标记为已解决，您可以使用 git add，并在完成后提交您的工作:

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

注意 git checkout 命令中的 ..这非常重要，而且很容易错过.git checkout 有两种模式；一种是切换分支，另一种是将文件从索引中检出到工作副本中(有时首先将它们从另一个修订版拉入索引).它区分的方式是你是否传入了文件名；如果你没有传入文件名，它会尝试切换分支(尽管如果你也没有传入分支，它只会再次尝试检查当前分支)，但如果有修改过的文件，它会拒绝这样做那会影响.因此，如果您想要覆盖现有文件的行为，则需要传入 . 或文件名，以便从 git checkout 获取第二个行为.

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.

在传入文件名时，用--偏移也是一个好习惯，比如git checkout --ours -- .如果您不这样做，并且文件名恰好与分支或标签的名称匹配，Git 会认为您想要检查该修订版，而不是检查该文件名，因此使用 <代码>结帐命令.

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.

我将详细介绍如何冲突和 合并 在 Git 中的工作.当您合并其他人的代码时(这也发生在拉取过程中；拉取本质上是先取后合并)，几乎没有可能出现的情况.

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.

另一种可能性是他们的修订版只是你的后代，在这种情况下，默认情况下你会有一个快进合并"，其中你的 HEAD 只是更新到他们的提交，没有发生合并(如果您真的想记录合并，可以使用 --no-ff 禁用此功能).

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

然后您会遇到实际需要合并两个修订版的情况.在这种情况下，有两种可能的结果.一是合并发生得很干净；所有更改都在不同的文件中，或者在相同的文件中，但相距足够远，可以毫无问题地应用两组更改.默认情况下，当干净合并发生时，它会自动提交，但如果您需要事先编辑它(例如，如果您重命名函数 ，您可以使用 --no-commit 禁用它foo 到 bar，并且其他人添加了调用 foo 的新代码，它将干净地合并，但会产生一个损坏的树，因此您可能需要清理它作为合并提交的一部分，以避免任何损坏的提交).

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

最后一种可能是真正的合并，并且存在冲突.在这种情况下，Git 将尽可能多地进行合并，并生成带有冲突标记的文件(<<<<<<<, ======== 和 >>>>>>>) 在您的工作副本中.在索引(也称为暂存区"；提交文件之前由 git add 存储文件的地方)中，每个文件都会有 3 个版本存在冲突；有来自您要合并的两个分支的祖先的文件的原始版本，来自 HEAD(合并的一侧)的版本，以及来自远程分支的版本.

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.

为了解决冲突，您可以编辑工作副本中的文件，删除冲突标记并修复代码以使其正常工作.或者，您可以使用 git checkout --ours 或 git checkout --theirs 从合并的一侧或另一侧检查版本.一旦你把文件放到你想要的状态，你就表明你已经完成了文件的合并，可以使用 git add 提交，然后你可以用 提交合并git commit.

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屋！