Was ist die genaue Bedeutung von "unser" und "ihr" in Git?

Question

Dies klingt vielleicht wie eine zu grundlegende Frage, aber ich habe nach Antworten gesucht und bin jetzt mehr verwirrt als zuvor.

Was bedeuten "ours" und "theirs" in git, wenn ich meinen Branch in meinen anderen Branch integriere? Beide Branches sind "ours".

Bei einem Mergekonflikt ist "ours" immer die obere der beiden angezeigten Versionen?

Bezieht sich "ours" immer auf den Branch, auf den HEAD zeigte, als der Merge begonnen wurde? Wenn ja, warum nicht eine klare possessive Bezugnahme wie "current branch's" verwenden, anstatt ein besitzanzeigendes Pronomen wie "ours" zu verwenden, das referentiell mehrdeutig ist (da beide Branches technisch gesehen uns gehören)?

Oder verwenden Sie einfach den Branch-Namen (statt "ours" zu sagen, sagen Sie einfach "local master's" oder ähnliches)?

Der verwirrendste Teil für mich ist, wenn ich in einer bestimmten Branches .gitattributes-Datei spezifiziere. Angenommen, in test branch habe ich folgende .gitattributes-Datei:

config.xml merge=ours

Jetzt wechsle ich den Branch und zeige HEAD auf master an, dann führe ich test zusammen. Da master 'ours' ist und die .gitattributes von test nicht ausgecheckt ist, wird es überhaupt eine Auswirkung haben? Wenn ja, da master jetzt "uns gehört", was wird passieren?

Answer 1

Ich werde mein Memo hier posten, weil ich immer wieder hierher zurückkommen muss.

SZENARIO 1. Normaler Entwickler: Sie sind ein Entwickler, der nicht in der Lage ist, in den master zu mergen und nur mit feature Branches arbeiten muss.

Fall 1: Master ist König. Sie möchten Ihren feature Branch aktualisieren (= rebase auf master), weil master neue Updates von Abhängigkeiten enthält und Sie Ihre bescheidenen Änderungen überschreiben möchten.

git checkout master
git pull

git checkout feature
git rebase -X ours master

Fall 2: Sie sind König. Sie möchten Ihren feature Branch auf die Änderungen im master rebasen. Aber Sie haben mehr gemacht als Ihre Kollegen und möchten Ihre eigenen Änderungen priorisieren.

git checkout master
git pull

git checkout feature
git rebase -X theirs master

WICHTIG: Wie Sie sehen können, sollten normale Entwickler rebase bevorzugen und es jeden Morgen wiederholen wie Übungen/Kaffee.

SZENARIO 2. Merge-Sensei: Sie sind ein Teamleiter und möchten andere Branches mergen und das zusammengeführte Ergebnis direkt in den master pushen. master ist ein Branch, den Sie ändern werden.

Fall 1: Master ist König Sie möchten einen Branch von Drittanbietern mergen, aber master hat Priorität. feature ist ein Branch, den Ihr Vorgesetzter gemacht hat.

git checkout feature
git pull

git checkout master
git merge -X ours feature

Fall 2: Neue Änderungen sind König Wenn Ihr leitender Entwickler ein cooles feature veröffentlicht hat und Sie den alten Mist im master Branch überschreiben möchten.

git checkout feature
git pull

git checkout master
git merge -X theirs feature

ERINNERUNG: Um sich um Mitternacht zu erinnern, welchen man wählen soll: master ist IMMER ours. Und theirs ist ein feature, das sie gemacht haben.

Answer 2

Nur zur Klarstellung - wie oben erwähnt, wird beim Neu-Basieren der Sinn umgekehrt, also wenn du

<<<<<<< HEAD
        foo = 12;
=======
        foo = 22;
>>>>>>> [deine Commit-Nachricht]

Auflösen mit 'meins' -> foo = 12

Auflösen mit 'theirs' -> foo = 22

Answer 3

--ours ist HEAD und --theirs ist REBASE_HEAD, MERGE_HEAD oder CHERRY_PICK_HEAD. Ich finde es viel weniger verwirrend, die Commit-Verweise direkt zu verwenden.

Beim Rebasieren:

git restore HEAD thing.js         # Verwende das, was der aktuelle Branch hat
git restore REBASE_HEAD thing.js  # Verwende das, was der andere Branch hat

Beim Mergen:

git restore HEAD thing.js        # Verwende das, was der aktuelle Branch hat
git restore MERGE_HEAD thing.js  # Verwende das, was der andere Branch hat

Beim Cherry-Picking:

git restore HEAD thing.js              # Verwende das, was der aktuelle Branch hat
git restore CHERRY_PICK_HEAD thing.js  # Verwende das, was der andere Branch hat

Answer 4

Von der Verwendung von git checkout:

-2, --ours            unsere Version für nicht zusammengeführte Dateien auschecken
-3, --theirs           ihre Version für nicht zusammengeführte Dateien auschecken
-m, --merge            eine 3-Wege-Zusammenführung mit dem neuen Branch durchführen

Beim Lösen von Zusammenführungskonflikten können Sie git checkout --theirs some_file und git checkout --ours some_file verwenden, um die Datei auf die aktuelle bzw. die eingehende Version zurückzusetzen.

Wenn Sie git checkout --ours some_file oder git checkout --theirs some_file ausgeführt haben und die Datei auf die 3-Wege-Zusammenführungsversion zurücksetzen möchten, können Sie dies mit git checkout --merge some_file tun.

Answer 5

Es gibt keine genaue Bedeutung, genau wegen dieser Begriffe, die je nachdem, ob Sie zusammenführen oder neu basieren, das Gegenteil bedeuten. DIE natürliche Art, über zwei Zweige nachzudenken, ist "meine Arbeit" und "die Arbeit von jemand anderem". Die Wahl der Terminologie, die diese Klassifizierung verschleiert, ist absolut DIE schlechteste Designentscheidung in Git. Es muss von der "Soll" und "Haben" oder "Aktiva" und "Passiva" der Buchhaltung inspiriert worden sein - derselbe Kopfschmerz.