git中「我們」和「他們的」的確切含義是什麼？

Question

這可能聽起來像一個問題的基本問題，但我已經尋找答案，我現在比以前更困惑。

當我的分支合併到其他分支時，「我們」和「他們的」在git中意味着什麼？ 這兩個分支都是「我們的」。

在合併衝突中，「我們」總是顯示兩個版本中的較高者？

「我們」是否總是指合併開始時HEAD指向的分支？如果是這樣，那麼爲什麼不使用像「當前分支」這樣的明確的所有權參考，而不是使用像「我們的」這樣的所有格代名詞（這是因爲兩個分支在技術上都是我們的）在所有格代詞中呢？

或者只是使用分支名稱（而不是說「我們的」只是說「本地主」或這樣的）？

對我來說最令人困惑的部分是如果我在特定分支的.gitattributes文件中指定。在測試分支可以說我有以下.gitattributes文件：

config.xml merge=ours 

現在我籤，並指向頭主然後在測試合併。由於主人是我們的，並且測試的.gitattributes沒有簽出，它會有效果嗎？如果確實有效果，因爲主人現在是「我們的」，那麼會發生什麼？

Answer 1

我懷疑你在這裏感到困惑，因爲它基本上令人困惑。更糟糕的是，當你正在進行rebase時，整個我們的/他們的東西會交換角色（變得倒退）。

最終，git merge過程中，「我們的」分支是指你歸併分支爲：

git checkout merge-into-ours 

和「他們」分支是指你的（單）分支合併：

git merge from-theirs 

這裏「我們」和「他們」有一定道理，因爲，即使「他們」可能是你的，無論如何，「他們」是不是你在是當您運行一。

雖然使用實際的分支名稱可能非常酷，但在更復雜的情況下會分崩離析。例如，您可以執行以下操作：

git checkout ours 
git merge 1234567 

您正在通過原始提交ID合併的位置。更糟的是，你甚至可以做到這一點：

在這種情況下

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

有不涉及分支的名字！

我覺得這裏有一點幫助，但事實上，在gitrevisions syntax，您可以通過數字指單個路徑索引，一個矛盾的合併過程中

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

第1階段是共同的祖先文件stage＃2是目標分支版本，stage＃3是您要合併的版本。

---

究其原因，「我們」和「他們」的概念是否會在rebase左右交換的是，做了一系列的櫻花選秀權重訂工作，到一個匿名的分支（分離的頭模式）。目標分支是匿名分支，合併分支是原始分支（前分支）：所以「--ours」表示匿名分支正在建設，而「 - 他們」意味着「我們的分支正在重新分配」 。

---

對於gitattributes條目：它可能有效果：「我們的」真表示「使用階段＃2」內。但正如你注意到的那樣，它當時並不實際，所以不應該在這裏產生效果......好吧，除非你在開始之前將它複製到工作樹中。另外，順便說一下，這適用於我們和他們的所有用途，但有些用於整個文件級別（合併策略爲-s ours;合併衝突期間爲git checkout --ours），並且有些是逐條提供的， （-s recursive合併期間的-X ours或-X theirs）。這可能無助於任何混淆。

雖然我從來沒有想出一個更好的名字。並且：請參閱VonC's answer另一個問題，其中git mergetool爲這些引入更多名稱，稱它們爲「本地」和「遠程」！

Answer 2

Git中的'我們的'是指具有git歷史的權威/規範部分的原始工作分支。

'他們的'指的是保存作品的版本爲rebased（要重播到當前分支上的更改）。

這可能會被交換到的人誰不知道，做基礎重建（如git rebase）實際上是把你擱置的工作（這是他們）以重播到規範/主要歷史是我們的，因爲我們正在將我們的更改重新定爲第三方工作。

爲git-checkout文檔在GIT中被進一步澄清> =每f303016 commit 2.5.1爲：

--ours --theirs

當檢出從索引路徑，檢查階段＃2 （ '我們'）或＃3（'他們的'）沒有路徑。

請注意，在git rebase和git pull --rebase期間，「我們」和「他們的」可能會出現交換; --ours給出了分支版本的變更重新分配到的版本，而--theirs給出了分支的版本，該分支包含正在重新分配的工作。

這是因爲rebase用於將遠程歷史記錄視爲共享規範的工作流，並將待分配的分支上的工作視爲要整合的第三方工作，而您暫時承擔亞歷山大期間經典歷史的守護者的角色。作爲規範歷史的守護者，您需要從遠程查看歷史記錄，如ours（即「我們的共享規範歷史記錄​​」），而您在您的支行上做的事情爲theirs（即「一個貢獻者在其上的工作」 ）。

對於git-merge它以下列方式解釋：

我們

此選項強制衝突的帥哥是自動解決通過支持我們的版本乾淨。來自另一棵與我們不衝突的樹的變化反映到合併結果。對於二進制文件，整個內容都是從我們這邊拿來的。

這不應該與我們的合併策略混淆，它甚至不會查看其他樹包含的東西。它丟棄了另一棵樹所做的一切，宣佈我們的歷史包含了發生在其中的所有事情。

他們

這是我們的相反。

更進一步，在這裏解釋如何使用它們：

合併機制（git merge和git pull命令）允許後端的合併策略與-s選項選擇。有些策略也可以採用自己的選項，可以通過將-X<option>參數傳遞給git merge和/或git pull來傳遞。

---

所以有時它可能會造成混淆，例如：

• git pull origin master其中-Xours是我們的地方，-Xtheirs是他們（遠程）分支
• git pull origin master -r其中-Xours是他們（遠程） ，-Xtheirs是我們的

因此，第二個例子與第一個例子相反，因爲我們將分支放在遠程分支上，所以我們的出發點是遠程分支，並將我們的更改視爲外部分支。

與git merge策略類似（-X ours和-X theirs）。

Answer 3

• 我們：這是你現在的分支。
• 他們的：這是您的行動中使用的其他分支。

所以，如果你是在分支發佈/ 2.5和您合併分支功能/新按鈕進去，然後在發佈找到的內容/ 2.5是什麼我們指和在功能上找到的內容/新按鈕就是他們的所指的內容。在合併過程中，這非常簡單。

大多數人所遇到的唯一問題是發生變形的情況。如果你做了一個重新的基礎而不是一個正常的合併，角色被交換了。怎麼樣？那麼，這完全是由於重組工作的方式。想想底墊這樣的工作：

1. 所有提交你做了自上次拉被移動到自己的一個分支，讓我們將其命名爲BranchX。
2. 您檢出當前分支的頭部，丟棄任何本地 更改，但以這種方式檢索其他人推送給該分支的所有更改。
3. 現在BranchX的每一次提交都是按照舊到新的順序對您當前的分支進行挑選。
4. BranchX被再次刪除，因此不會出現在任何歷史記錄中。

當然，這並不是真的發生了什麼，但對我來說這是一個很好的思維模型。如果你看2和3，你就會明白爲什麼這些角色已經交換了。從2開始，您當前的分支現在是來自服務器的沒有任何更改的分支，因此這是我們的（您所在的分支）。您所做的更改現在位於不是您當前的分支（BranchX），因此這些更改（儘管是您所做的更改）是他們的（您的操作中使用的其他分支）。

這意味着如果你合併，並且你希望你的改變永遠勝利，你會告訴git總是選擇「我們的」，但是如果你改變了，並且你希望你所有的改變總是獲勝，那麼你告訴git總是選擇「他們的」。