在Git版本控制系统中，处理合并冲突是日常工作中不可避免的一部分，尤其是当多个开发者在相同的代码库上并行工作时。Git提供了多种策略来解决这些冲突，其中`theirs`选项是一种在合并冲突时自动选择对方（或称为“他们的”）更改的策略，而不考虑当前分支（或称为“我们的”）的更改。 ### Git 中的 theirs 选项 直接来说，Git命令本身并不直接提供一个名为`theirs`的合并选项，如同`git merge --theirs`这样的命令并不存在。但是，`theirs`策略的概念可以通过其他Git命令和技巧来实现，特别是在解决合并冲突时。 ### 如何用 theirs 解决合并冲突 虽然Git没有直接的`--theirs`选项，但你可以通过几种方式来实现类似于选择对方更改的效果： #### 1. 使用`git checkout`（或`git restore`在较新版本中） 当遇到合并冲突时，Git会标记冲突的文件。你可以手动检查这些文件，并使用`git checkout --theirs `来接受对方分支的更改（Git 2.23之前使用`git checkout`，之后推荐使用`git restore --source=HEAD:2 --staged --worktree -- `，因为`git checkout`的用途在逐渐变化）。这里需要注意，`--theirs`和`--ours`选项在`git checkout`命令中并不直接存在，但可以通过引用合并中特定提交的内容来间接实现。 #### 示例： 假设你在合并`feature`分支到`main`分支时遇到了冲突，并决定接受`feature`分支的所有更改： ```bash # 假设你已经开始了合并操作并遇到了冲突 git merge feature # 列出所有冲突的文件 git status # 逐个解决冲突，接受feature分支的更改 git restore --source=MERGE_HEAD --staged --worktree -- # 或者，如果你知道合并的提交哈希，可以直接使用它 # git restore --source= --staged --worktree -- # 重复上述步骤解决所有冲突 # 完成合并 git add . git commit -m "Merge feature into main, resolving conflicts in favor of feature" ``` 注意：`MERGE_HEAD`是一个特殊的引用，指向你正在合并的分支的最新提交。 #### 2. 使用`git merge`的`--strategy-option` 虽然这不是直接应用`theirs`策略的方式，但某些合并策略（如`ours`或`subtree`）的变体或自定义合并驱动可能允许更细粒度的控制。然而，对于简单的“总是选择对方更改”的场景，直接手动解决冲突通常更直接和灵活。 #### 3. 重新考虑合并策略 如果经常需要选择对方分支的更改，可能需要重新考虑合并的时机或分支策略。例如，可以使用`git rebase`而不是`git merge`来将更改“重放”到另一个分支上，这通常可以避免许多合并冲突。 ### 结论 虽然Git没有直接的`--theirs`选项，但你可以通过手动解决冲突时选择对方分支的更改，或者使用`git restore`（或`git checkout`，取决于你的Git版本）来模拟这一行为。高级程序员在处理这类问题时，会考虑合并的上下文、分支策略以及团队的协作方式，以找到最适合当前情况的解决方案。在`码小课`这样的平台上分享这些经验和技巧，可以帮助更多开发者提高版本控制技能，减少合并冲突带来的困扰。