git中“我们的”和“他们的”的确切含义是什么？

蔚落 2022-11-26 08:49 783阅读 0赞

本文翻译自：[What is the precise meaning of “ours” and “theirs” in git?][What is the precise meaning of _ours_ and _theirs_ in git]

*This might sound like too basic of a question, but I have searched for answers and I am more confused now than before.* **这听起来像是一个问题的基本知识，但是我一直在寻找答案，现在我比以前更加困惑。**

*What does "ours" and "theirs" mean in git when merging my branch into my other branch?* **将我的分支合并到另一个分支时，git中的“我们的”和“他们的”是什么意思？** *Both branches are "ours".* **两个分支都是“我们的”。**

*In a merge conflict is "ours" always the upper of the two versions displayed?* **在合并冲突中，“我们的”是否总是显示两个版本中的较高者？**

*Does "ours" always refer to the branch that HEAD was pointing to when the merge began?* **“我们的”是否总是指合并开始时HEAD指向的分支？** *If so then why not use a clear possessive reference like "current branch's" instead of using a possessive pronoun like "ours" that is referentially ambiguous (since both branches are technically ours)?* **如果是这样，那为什么不使用诸如“当前分支”之类的清晰所有格代词，而不是使用指称性模棱两可的“我们”之类的所有格代词（因为这两个分支在技术上都是我们的）？**

*Or just use the branch name (instead of saying "ours" just say "local master's" or such)?* **还是只使用分支名称（而不是说“我们的”，而要说“本地主人的”等）？**

*The most confusing part to me is if I specify in a specific branch's .gitattributes file.* **我最困惑的部分是，如果我在特定分支的.gitattributes文件中指定。** *Lets say in **test branch** I have the following .gitattributes file:* **可以说在测试分支中，我有以下.gitattributes文件：**

config.xml merge=ours

*Now I checkout and point HEAD to **master** then merge in **test** .* **现在我结帐，将HEAD指向master，然后合并到test中 。** *Since **master** is ours, and **test** 's .gitattributes is not checked out, will it even have an effect?* **由于master是我们的主人 ，并且test的.gitattributes未检出，它甚至会起作用吗？** *If it does have an effect, since **master** is now "ours", then what will happen?* **如果确实有效果，那么既然主人现在是我们的，那将会发生什么？**

--------------------

### \#1楼 ###

参考：[https://stackoom.com/question/1JjAP/git中-我们的-和-他们的-的确切含义是什么][https_stackoom.com_question_1JjAP_git_-_-_-_-]

--------------------

### \#2楼 ###

*I suspect you're confused here because it's fundamentally confusing.* **我怀疑您在这里感到困惑，因为这从根本上来说是令人困惑的。** *To make things worse, the whole ours/theirs stuff switches roles (becomes backwards) when you are doing a rebase.* **更糟的是，当您进行基准调整时，我们/他们的整个工作切换角色（倒退）。**

*Ultimately, during a `git merge` , the "ours" branch refers to the branch you're merging into :* **最终，在`git merge`期间，“我们的”分支是指您要合并*到*的分支：**

git checkout merge-into-ours

*and the "theirs" branch refers to the (single) branch you're merging:* **而“他们的”分支是指您要合并的（单个）分支：**

git merge from-theirs

*and here "ours" and "theirs" makes some sense, as even though "theirs" is probably yours anyway, "theirs" is not the one you were on when you ran `git merge` .* **这里“我们”和“他们”有一定道理，因为，即使“他们”可能是你的，无论如何，“他们”是不是你*就*当你运行一个`git merge` 。**

*While using the actual branch name might be pretty cool, it falls apart in more complex cases.* **虽然使用实际的分支名称可能很酷，但在更复杂的情况下会分崩离析。** *For instance, instead of the above, you might do:* **例如，代替上面的方法，您可以这样做：**

git checkout ours
    git merge 1234567

*where you're merging by raw commit-ID.* **您通过原始提交ID合并的位置。** *Worse, you can even do this:* **更糟糕的是，您甚至可以执行以下操作：**

git checkout 7777777    # detach HEAD
    git merge 1234567       # do a test merge

*in which case there are no branch names involved!* **在这种情况下， *不*涉及分支名称！**

*I think it's little help here, but in fact, in [`gitrevisions` syntax][gitrevisions_ syntax] , you can refer to an individual path in the index by number, during a conflicted merge* **我认为这没有什么帮助，但是实际上，在[`gitrevisions`语法中][gitrevisions_ syntax] ，在发生冲突的合并期间，您可以按数字引用索引中的单个路径**

git show :1:README
    git show :2:README
    git show :3:README

*Stage \#1 is the common ancestor of the files, stage \#2 is the target-branch version, and stage \#3 is the version you are merging from.* **阶段1是文件的共同祖先，阶段2是目标分支版本，阶段3是您要从中合并的版本。**

--------------------

*The reason the "ours" and "theirs" notions get swapped around during `rebase` is that rebase works by doing a series of cherry-picks, into an anonymous branch (detached HEAD mode).* **在“我们”和“他们”的概念在被换周围的理由`rebase`是重订工作做了一系列的樱花选秀权，成为一个匿名的分支（分离的头模式）。** *The target branch is the anonymous branch, and the merge-from branch is your original (pre-rebase) branch: so "--ours" means the anonymous one rebase is building while "--theirs" means "our branch being rebased".* **目标分支是匿名分支，而merge-from分支是您的原始（重新设置基准）分支：因此，“-我们的”表示正在建立匿名的一个基准，而“-他们的”表示“正在重新建立我们的分支” 。**

--------------------

*As for the gitattributes entry: it could have an effect: "ours" really means "use stage \#2" internally.* **至于gitattributes条目：它*可能*会产生影响：“我们的”实际上是在内部表示“使用阶段2”。** *But as you note, it's not actually in place at the time, so it should not have an effect here ... well, not unless you copy it into the work tree before you start.* **但是正如您所注意到的，它当时实际上*并不*存在，因此它*应该不会*在这里起作用……好吧，除非您在开始之前将其复制到工作树中，否则不会这样做。**

*Also, by the way, this applies to all uses of ours and theirs, but some are on a whole file level ( `-s ours` for a merge strategy; `git checkout --ours` during a merge conflict) and some are on a piece-by-piece basis ( `-X ours` or `-X theirs` during a `-s recursive` merge).* **另外，顺便说一句，这适用于我们及其使用的所有用途，但是有些用途在整个文件级别（ `-s ours`的合并策略； `git checkout --ours`在合并冲突期间使用），而有些则处于`git checkout --ours`状态-逐个基础（在`-s recursive`合并过程中`-X ours`或`-X theirs` ）。** *Which probably does not help with any of the confusion.* **这可能无助于解决任何混乱。**

*I've never come up with a better name for these, though.* **不过，我从来没有想出一个更好的名字。** *And: see [VonC's answer][VonC_s answer] to another question, where `git mergetool` introduces yet more names for these, calling them "local" and "remote"!* **并且：请参见[VonC][VonC_s answer]对另一个问题[的回答][VonC_s answer] ，其中`git mergetool`为它们引入了更多名称，称它们为“本地”和“远程”！**

--------------------

### \#3楼 ###

*The ' **ours** ' in Git is referring to the original working branch which has authoritative/canonical part of git history.* **Git中的“ 我们的 ”是指原始工作分支，该分支具有git历史的权威/规范部分。**

*The ' **theirs** ' refers to the version that holds the work in order to be [rebased][] (changes to be replayed onto the current branch).* **“ 他们的 ”指的是保存作品以便进行[基础][rebased]更改（将更改重播到当前分支上）的版本。**

*This may appear to be swapped to people who are not aware that doing rebasing (eg `git rebase` ) is actually taking your work on hold (which is theirs ) in order to replay onto the canonical/main history which is ours , because we're rebasing our changes as third-party work.* **这似乎交换给了那些不知道进行重新定标（例如`git rebase` ）实际上正在搁置您的工作（这是*他们的工作* ）的人，以便重播属于*我们*的规范/主要历史，因为我们将我们的更改作为第三方工作。**

*The documentation for `git-checkout` was further clarified in Git >=2.5.1 as per [`f303016` commit][f303016_ commit] :* **`git-checkout`的文档根据[`f303016` commit][f303016_ commit]在Git> = 2.5.1中进一步阐明：**

> *`--ours` `--theirs`* **`--ours` `--theirs`**
> 
> *When checking out paths from the index, check out stage \#2 ('ours') or \#3 ('theirs') for unmerged paths.* **从索引中检出路径时，请检出第2阶段（“我们的”）或第3阶段（“ theirs”）的未合并路径。**
> 
> *Note that during `git rebase` and `git pull --rebase` , 'ours' and 'theirs' may appear swapped;* **注意，在`git rebase`和`git pull --rebase` ，“我们的”和“他们的”可能会互换；** *`--ours` gives the version from the branch the changes are rebased onto, while `--theirs` gives the version from the branch that holds your work that is being rebased.* **`--ours`提供更改所基于的分支的版本，而`--theirs`提供保存要重新构建的工作的分支的版本。**
> 
> *This is because `rebase` is used in a workflow that treats the history at the remote as the shared canonical one, and treats the work done on the branch you are rebasing as the third-party work to be integrated, and you are temporarily assuming the role of the keeper of the canonical history during the rebase.* **这是因为在工作流中使用了`rebase` ，该工作流将远程站点上的历史记录视为共享规范，并将您要重新部署的分支上完成的工作视为要集成的第三方工作，并且您暂时担当了该角色改组期间的规范历史保持者的身份。** *As the keeper of the canonical history, you need to view the history from the remote as `ours` (ie "our shared canonical history"), while what you did on your side branch as `theirs` (ie "one contributor's work on top of it").* **作为规范历史的维护者，您需要从远程查看与`ours`一样的历史（即“我们共享的规范历史”），而您在分支机构所做的工作就是作为`theirs` （即“一个贡献者的工作”）。 ）。**

*For [`git-merge`][git-merge] it's explain in the following way:* **对于[`git-merge`][git-merge]其解释如下：**

> ***ours*** **我们的**
> 
> *This option forces conflicting hunks to be auto-resolved cleanly by favoring our version.* **通过支持我们的版本，此选项可以强制自动解决冲突的大块。** *Changes from the other tree that do not conflict with our side are reflected to the merge result.* **与另一棵树不冲突的更改会反映到合并结果中。** *For a binary file, the entire contents are taken from our side.* **对于二进制文件，全部内容都是从我们这边获取的。**
> 
> *This should not be confused with the ours merge strategy, which does not even look at what the other tree contains at all.* **这不应与我们的合并策略混淆，该策略甚至根本不看另一棵树包含的内容。** *It discards everything the other tree did, declaring our history contains all that happened in it.* **它丢弃另一棵树所做的所有操作，声明我们的历史包含其中发生的所有事件。**
> 
> ***theirs*** **他们的**
> 
> *This is the opposite of ours.* **这与我们的相反。**

*Further more, here is explained how to use them:* **此外，这里说明了如何使用它们：**

> *The merge mechanism ( `git merge` and `git pull` commands) allows the backend merge strategies to be chosen with `-s` option.* **合并机制（ `git merge`和`git pull`命令）允许使用`-s`选项选择后端合并策略。** *Some strategies can also take their own options, which can be passed by giving `-X<option>` arguments to `git merge` and/or `git pull` .* **一些策略也可以采用自己的选项，可以通过为`git merge`和/或`git pull`提供`-X<option>`参数来传递它们。**

--------------------

*So sometimes it can be confusing, for example:* **因此有时可能会令人困惑，例如：**

*  *`git pull origin master` where `-Xours` is our local, `-Xtheirs` is theirs (remote) branch* **`git pull origin master` ，其中`-Xours`是我们的本地， `-Xtheirs`是他们的（远程）分支**
 *  *`git pull origin master -r` where `-Xours` is theirs (remote), `-Xtheirs` is ours* **`git pull origin master -r` ，其中`-Xours`是他们的（远程），- `-Xtheirs`是我们的**

*So the 2nd example is opposite to the 1st one, because we're rebasing our branch on top of the remote one, so our starting point is remote one, and our changes are treated as external.* **因此，第二个示例与第一个示例相反，因为我们将分支重新建立在远程分支的顶部，所以我们的出发点是远程分支，而我们所做的更改被视为外部的。**

*Similar for `git merge` strategies ( `-X ours` and `-X theirs` ).* **与`git merge`策略相似（ `-X ours`和`-X theirs` ）。**

--------------------

### \#4楼 ###

*  *Ours : This is the branch you are currently on.* ***我们的* ：这是您当前所在的分支。**
 *  *Theirs : This is the other branch that is used in your action.* ***他们的* ：这是您的操作中使用的另一个分支。**

*So if you are on branch release/2.5 and you merge branch feature/new-buttons into it, then the content as found in release/2.5 is what ours refers to and the content as found on feature/new-buttons is what theirs refers to.* **因此，如果您使用的是分支*版本/2.5，*并且将分支*功能/新按钮*合并到其中，那么*发布* */2.5中*的内容就是*我们*所指的内容，而*功能/新按钮*上的内容就是*他们*所指的内容至。** *During a merge action this is pretty straight forward.* **在合并操作期间，这非常简单。**

*The only problem most people fall for is **the rebase case** .* **大多数人唯一的问题是重新定案 。** *If you do a re-base instead of a normal merge, the roles are swapped.* **如果执行重新基准而不是常规合并，则角色将互换。** *How's that?* **怎么样？** *Well, that's caused solely by the way rebasing works.* **好吧，这完全是由重新定基的方式引起的。** *Think of rebase to work like that:* **考虑重新设计工作，像这样：**

1.  *All commits you have done since your last pull are moved to a branch of their own, let's name it BranchX .* **自上次拉取以来，您所做的所有提交都移到了自己的分支中，我们将其命名为*BranchX* 。**
2.  *You checkout the head of your current branch, discarding any local changes you had but that way retrieving all changes others have pushed for that branch.* **您签出当前分支的头，放弃您所做的任何本地更改，但以此方式检索其他人为该分支推送的所有更改。**
3.  *Now every commit on BranchX is cherry-picked in order old to new to your current branch.* **现在， *BranchX*上的每个提交*都是精心*挑选的，以便从旧到新到当前分支。**
4.  *BranchX is deleted again and thus won't ever show up in any history.* ***BranchX*再次被删除，因此永远不会出现在任何历史记录中。**

*Of course, that's not really what is going on but it's a nice mind model for me.* **当然，这并不是真正发生的事情，但这对我来说是一个不错的思维模型。** *And if you look at 2 and 3, you will understand why the roles are swapped now.* **如果您查看2和3，您将了解为什么现在要互换角色。** *As of 2, your current branch is now the branch from the server without any of your changes, so this is ours (the branch you are on).* **从2开始，您当前的分支现在是服务器的分支，无需进行任何更改，因此这就是*我们*的分支（您所在的分支）。** *The changes you made are now on a different branch that is not your current one ( BranchX ) and thus these changes (despite being the changes you made) are theirs (the other branch used in your action).* **您所做的更改现在位于当前分支（ *BranchX* ）以外的其他分支上，因此这些更改（尽管是您所做的更改）是*它们*的更改（您的操作中使用的另一个分支）。**

*That means if you merge and you want your changes to always win, you'd tell git to always choose "ours" but if you rebase and you want all your changes to always win, you tell git to always choose "theirs".* **这意味着如果您合并并且希望您的更改始终获胜，则会告诉git始终选择“我们的”，但是如果您重新定基并且希望所有更改都始终获胜，则会告诉git始终选择“他们的”。**

--------------------

### \#5楼 ###

*I know this has been answered, but this issue confused me so many times I've put up a small reference website to help me remember: [https://nitaym.github.io/ourstheirs/][https_nitaym.github.io_ourstheirs]* **我知道已经解决了这个问题，但是这个问题使我困惑了很多次，我建立了一个小型参考网站来帮助我记住： [https][https_nitaym.github.io_ourstheirs] : [//nitaym.github.io/ourstheirs/][https_nitaym.github.io_ourstheirs]**

*Here are the basics:* **以下是基本知识：**

## *Merges:* **合并：** ##

$ git checkout master 
    $ git merge feature

*If you want to select the version in `master` :* **如果要在`master`选择版本：**

$ git checkout --ours codefile.js

*If you want to select the version in `feature` :* **如果要在`feature`选择版本：**

$ git checkout --theirs codefile.js

## *Rebases:* **变基：** ##

$ git checkout feature 
    $ git rebase master

*If you want to select the version in `master` :* **如果要在`master`选择版本：**

$ git checkout --ours codefile.js

*If you want to select the version in `feature` :* **如果要在`feature`选择版本：**

$ git checkout --theirs codefile.js

*(This is for complete files, of course)* **（当然，这是完整的文件）**

--------------------

### \#6楼 ###

*From `git checkout` 's usage:* **从`git checkout`的用法：**

-2, --ours            checkout our version for unmerged files
    -3, --theirs          checkout their version for unmerged files
    -m, --merge           perform a 3-way merge with the new branch

*When resolving merge conflicts, you can do `git checkout --theirs some_file` , and `git checkout --ours some_file` to reset the file to the current version and the incoming versions respectively.* **解决合并冲突时，可以执行`git checkout --theirs some_file`和`git checkout --ours some_file`将文件分别重置为当前版本和传入版本。**

*If you've done `git checkout --ours some_file` or `git checkout --theirs some_file` and would like to reset the file to the 3-way merge version of the file, you can do `git checkout --merge some_file` .* **如果您已经完成`git checkout --ours some_file`或`git checkout --theirs some_file`并想将文件重置为文件的三向合并版本，则可以执行`git checkout --merge some_file` 。**

[What is the precise meaning of _ours_ and _theirs_ in git]: https://oldbug.net/q/1JjAP/What-is-the-precise-meaning-of-ours-and-theirs-in-git
[https_stackoom.com_question_1JjAP_git_-_-_-_-]: https://stackoom.com/question/1JjAP/git%E4%B8%AD-%E6%88%91%E4%BB%AC%E7%9A%84-%E5%92%8C-%E4%BB%96%E4%BB%AC%E7%9A%84-%E7%9A%84%E7%A1%AE%E5%88%87%E5%90%AB%E4%B9%89%E6%98%AF%E4%BB%80%E4%B9%88
[gitrevisions_ syntax]: https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html
[VonC_s answer]: https://stackoverflow.com/questions/3051461/git-rebase-keeping-track-of-local-and-remote/3052118#3052118
[rebased]: https://git-scm.com/book/en/v2/Git-Branching-Rebasing
[f303016_ commit]: https://github.com/git/git/commit/f30301657b68561392d910f6196380dd3976549e
[git-merge]: https://git-scm.com/docs/git-merge
[https_nitaym.github.io_ourstheirs]: https://nitaym.github.io/ourstheirs/