我有一些本地文件，我从远程分支拉，有冲突。我知道我想保留本地更改并忽略导致冲突的远程更改。是否有一个命令可以用来实际上说“将所有冲突标记为已解决，使用本地”？
git checkout有--ours选项来检查你本地文件的版本（而不是--theirs，这是你提取的版本）。您可以将.传递给git checkout，告诉它检查树中的所有内容。然后你需要将冲突标记为已解决，你可以用git add做，并在完成后提交你的工作：
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获取第二个行为。
在传递文件名时，使用--（例如git checkout --ours -- <filename>）来抵消它也是一个好习惯。如果你不这样做，并且文件名恰好与分支或标签的名称相匹配，Git会认为你要检查该修订版本，而不是检查该文件名，所以使用checkout的第一种形式命令。
我将扩展一些关于冲突和merging如何在Git中工作的内容。当你合并其他人的代码时（在拉动期间也会发生这种情况;拉动本质上是一次提取然后合并），几乎没有可能的情况。
最简单的是你正在进行相同的修订。在这种情况下，你“已经是最新的”，没有任何反应。
另一种可能性是它们的修改只是你的后代，在这种情况下你默认会有一个“快进合并”，你的HEAD只是更新到它们的提交，没有合并发生（如果没有合并，这可能会被禁用）你真的想用--no-ff记录合并。
然后，您将进入实际需要合并两个修订版的情况。在这种情况下，有两种可能的结果。一个是合并干净;所有更改都在不同的文件中，或者在相同的文件中，但相隔足够远，以便可以毫无问题地应用这两组更改。默认情况下，当发生干净合并时，它会自动提交，但如果您需要事先编辑它，可以使用--no-commit禁用它（例如，如果您将函数foo重命名为bar，而其他人添加了调用foo的新代码，它将干净地合并，但产生一个破碎的树，所以你可能想要在合并提交的一部分清理它，以避免任何破坏的提交）。
最后的可能性是存在真正的合并，并且存在冲突。在这种情况下，Git将尽可能多地进行合并，并在工作副本中生成带有冲突标记（<<<<<<<，=======和>>>>>>>）的文件。在索引中（也称为“临时区域”; git add在提交文件之前存储文件的位置），每个文件的3个版本都会有冲突;您正在合并的两个分支的祖先中存在该文件的原始版本，来自HEAD（您的合并方）的版本以及远程分支的版本。
为了解决冲突，您可以编辑工作副本中的文件，删除冲突标记并修复代码以使其正常工作。或者，您可以使用git checkout --ours或git checkout --theirs查看合并的一侧或另一侧的版本。一旦你把文件放到你想要的状态，你就表明你已经完成了合并文件并且已准备好使用git add提交，然后你可以提交与git commit的合并。
确保冲突起源：如果它是git merge的结果，请参阅Brian Campbell的answer。
但如果是git rebase的结果，为了放弃远程（他们的）更改并使用本地更改，您必须执行以下操作：
git checkout --theirs -- .
请参阅“Why is the meaning of “ours” and “theirs” reversed"”以了解如何在rebase期间交换ours和theirs（因为签出了upstream分支）。