it-swarm.com.de

Was ist die genaue Bedeutung von "uns" und "ihnen" in git?

Das klingt vielleicht zu einfach für eine Frage, aber ich habe nach Antworten gesucht und bin jetzt verwirrter als zuvor.

Was bedeuten "unsere" und "ihre" in git, wenn ich meine Niederlassung in meine andere Niederlassung zusammenbringe? Beide Zweige sind "unsere". 

Wird bei einem Zusammenführungskonflikt "unsere" immer die obere der beiden Versionen angezeigt? 

Bezieht sich "unser" immer auf den Zweig, auf den HEAD verwiesen hat, als die Fusion begann? Wenn ja, dann warum nicht eine klare Possessivreferenz wie "aktuelle Verzweigungen" verwenden, anstatt ein Possessivpronomen wie "unsere" zu verwenden, das referenziell mehrdeutig ist (da beide Zweige technisch unsere sind)? 

Oder benutzen Sie einfach den Namen der Niederlassung (anstatt "unser" zu sagen, sagen Sie einfach "lokale Meister" oder so)?

Der verwirrendste Teil ist für mich, wenn ich in der .gitattributes-Datei eines bestimmten Zweigs angeben. Sagen wir in Testzweig Ich habe die folgende .gitattributes-Datei:

config.xml merge=ours

Jetzt checke ich aus und zeige HEAD auf master, dann füge ich test zusammen. Da master unser ist, und tests .gitattributes nicht ausgecheckt wird, hat dies überhaupt eine Wirkung? Wenn es einen Effekt hat, da master jetzt "unser" ist, was wird dann passieren?

218
CommaToast

Ich vermute, Sie sind hier verwirrt, weil es grundlegend verwirrend ist. Um das Ganze noch schlimmer zu machen, wechselt das Ganze bei uns eine Rolle (wird rückwärts), wenn Sie eine Rebase ausführen.

Während eines git merge bezieht sich der Zweig "unser" auf den Zweig, den Sie in einführen:

git checkout merge-into-ours

und der Zweig "ihrer" bezieht sich auf den (einzigen) Zweig, den Sie zusammenführen:

git merge from-theirs

und hier machen "unsere" und "ihre" einen Sinn, da "wahrscheinlich" sowieso auch "ihre" ist, "ihre" nicht die, die Sie waren on, als Sie git merge liefen.

Die Verwendung des tatsächlichen Zweignamens ist zwar ziemlich cool, fällt jedoch in komplexeren Fällen auseinander. Anstelle des Vorstehenden können Sie beispielsweise Folgendes tun:

git checkout ours
git merge 1234567

wo Sie nach reiner Commit-ID zusammengeführt werden. Schlimmer noch, Sie können dies sogar tun:

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

in diesem Fall sind no Zweignamen beteiligt!

Ich denke, es ist wenig hilfreich, aber in gitrevisions syntax können Sie während einer konfliktierten Verschmelzung auf einen einzelnen Pfad im Index anhand der Nummer verweisen

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

Stufe 1 ist der gemeinsame Vorfahr der Dateien, Stufe 2 ist die Zielzweigversion und Stufe 3 ist die Version, aus der Sie zusammenführen.


Der Grund, warum die "unsere" und "ihre" Vorstellung während rebase vertauscht werden, besteht darin, dass rebase eine Reihe von Kirschpicks in einen anonymen Zweig durchführt (separierter Modus HEAD). Der Zielzweig ist der anonyme Zweig, und der Zusammenführungszweig ist Ihr ursprünglicher Zweig (Pre-Rebase): "--ours" bedeutet, dass der anonyme Rebase aufgebaut wird, während "--theirs" bedeutet, dass unser Zweig neu basiert. .


Was den Eintrag gitattributes angeht: it könnte hat eine Auswirkung: "unsere" bedeutet wirklich "Stufe 2 verwenden". Wie Sie jedoch feststellen, ist es zu diesem Zeitpunkt noch nicht vorhanden, so dass sollte nichthier einen Effekt haben ... na ja, es sei denn, Sie kopieren es in den Arbeitsbaum, bevor Sie beginnen.

Übrigens gilt dies auch für alle Verwendungen unserer und ihrer eigenen, aber einige befinden sich auf Dateiebene (-s ours für eine Zusammenführungsstrategie; git checkout --ours während eines Zusammenführungskonflikts) und einige sind stückweise (-X ours). oder -X theirs während einer -s recursive-Zusammenführung). Das hilft wahrscheinlich bei keiner Verwirrung.

Ich habe jedoch noch nie einen besseren Namen dafür gefunden. Und: Siehe VonCs Antwort zu einer anderen Frage, bei der git mergetool noch mehr Namen für diese einführt, die sie "lokal" und "fern" nennen!

265
torek

Das 'ours' in Git bezieht sich auf den ursprünglichen Arbeitszweig, der einen autoritativen/kanonischen Teil der Git-Geschichte hat.

Das 'theirs' bezieht sich auf die Version, die die Arbeit enthält, um rebased (Änderungen, die auf dem aktuellen Zweig wiedergegeben werden sollen).

Dies kann anscheinend mit Personen ausgetauscht werden, die sich nicht bewusst sind, dass das Umbasieren (z. B. git rebase) Ihre Arbeit tatsächlich angehalten hat (dh ihre), um die kanonische/main-Historie unsere, weil wir unsere Änderungen als Arbeit von Drittanbietern umbasieren.

Die Dokumentation für git-checkout wurde in Git> = 2.5.1 gemäß f303016 commit weiter präzisiert.

--ours--theirs

Wenn Sie Pfade aus dem Index auschecken, überprüfen Sie Stufe 2 ('unsere') oder # 3 ('ihre') für nicht zusammengeführte Pfade.

Beachten Sie, dass während git rebase und git pull --rebase 'unsere' und 'ihre' möglicherweise vertauscht erscheinen. --ours gibt die Version des Zweigs an, auf die die Änderungen umgestaltet werden, während --theirs die Version des Zweigs angibt, in dem sich Ihre Arbeit befindet, die neu basiert wird.

Dies liegt daran, dass rebase in einem Workflow verwendet wird, der den Verlauf an der Remote-Station als gemeinsam genutzten kanonischen Vorgang behandelt und die Arbeit, die in dem Zweig ausgeführt wird, den Sie umbasieren, als Drittanbieter-Arbeit behandelt, die integriert werden soll des Bewahrers der kanonischen Geschichte während der Rebase. Als Bewahrer der kanonischen Geschichte müssen Sie den Verlauf der Fernbedienung als ours (dh "unsere gemeinsam genutzte kanonische Geschichte") anzeigen, während das, was Sie auf Ihrer Seite als theirs getan haben (dh "die Arbeit eines Mitwirkenden darüber") ).

Für git-merge wird es folgendermaßen erklärt:

unsere

Diese Option bewirkt, dass widersprüchliche Kerle durch die Bevorzugung unserer Version automatisch automatisch aufgelöst werden. Änderungen aus dem anderen Baum, die nicht mit unserer Seite in Konflikt stehen, werden im Zusammenführungsergebnis angezeigt. Bei einer Binärdatei wird der gesamte Inhalt von unserer Seite übernommen.

Dies sollte nicht mit der Ours-Merge-Strategie verwechselt werden, bei der nicht einmal untersucht wird, was der andere Baum überhaupt enthält. Es verwirft alles, was der andere Baum getan hat, und erklärt, dass unsere Geschichte alles enthält, was darin passiert ist.

ihre

Dies ist das Gegenteil von uns.

Weiter wird hier erklärt, wie man sie benutzt:

Der Merge-Mechanismus (Befehle git merge und git pull) ermöglicht die Auswahl der Backend-Zusammenführungsstrategien mit der Option -s. Einige Strategien können auch eigene Optionen haben, die durch Angabe von -X<option>-Argumenten an git merge und/oder git pull übergeben werden können.


So kann es manchmal verwirrend sein, zum Beispiel:

  • git pull Origin master Dabei ist -Xours unser lokaler, -Xtheirs ist ihr (entfernter) Zweig
  • git pull Origin master -r wobei -Xours für sie (remote) steht, -Xtheirs für uns

Das zweite Beispiel ist also dem ersten Beispiel entgegengesetzt, da wir unseren Zweig auf den entfernten Zweig umstellen, unser Ausgangspunkt also ein entfernter ist und unsere Änderungen als äußerlich behandelt werden.

Ähnlich für git merge-Strategien (-X ours und -X theirs).

33
kenorb

Ich weiß, dass dies beantwortet wurde, aber dieses Problem hat mich so oft verwirrt, dass ich eine kleine Referenz-Website eingerichtet habe, um mich daran zu erinnern: https://nitaym.github.io/ourstheirs/

Hier sind die Grundlagen:

Zusammenführen:

$ git checkout master 
$ git merge feature

Wenn Sie die Version in master auswählen möchten:

$ git checkout --ours codefile.js

Wenn Sie die Version in feature auswählen möchten:

$ git checkout --theirs codefile.js

Rebases:

$ git checkout feature 
$ git rebase master 

Wenn Sie die Version in master auswählen möchten:

$ git checkout --ours codefile.js

Wenn Sie die Version in feature auswählen möchten:

$ git checkout --theirs codefile.js

(Dies ist natürlich für vollständige Dateien)

27
Nitay
  • Ours: Dies ist der Zweig, in dem Sie sich gerade befinden.
  • Theirs: Dies ist der andere Zweig, der in Ihrer Aktion verwendet wird.

Wenn Sie sich also in Zweig release/2.5 befinden und Zweig feature/new-buttons darin einführen, dann bezieht sich der Inhalt in release/2.5 auf ours to und der Inhalt, wie er auf feature/new-buttons zu finden ist, ist das, worauf seine verweist. Während einer Merge-Aktion ist das ziemlich einfach.

Das einzige Problem, dem die meisten Leute verfallen, ist der Fall der Rebase . Wenn Sie statt einer normalen Zusammenführung eine erneute Basiskontrolle durchführen, werden die Rollen vertauscht. Wie ist das? Nun, das liegt allein an der Art und Weise, wie die Umbasierung funktioniert. Denken Sie an Rebase, um so zu arbeiten:

  1. Alle Commits, die Sie seit Ihrem letzten Pull ausgeführt haben, werden in einen eigenen Zweig verschoben, nennen wir ihn BranchX.
  2. Sie checken den Kopf Ihres aktuellen Zweiges und verwerfen alle lokalen Änderungen, die Sie hatten, aber auf diese Weise alle Änderungen abgerufen, die von anderen für diesen Zweig gepusht wurden.
  3. Jetzt wird jedes Commit für BranchX ausgewählt, um alte und neue zu Ihrer aktuellen Filiale zu machen.
  4. BranchX wird wieder gelöscht und erscheint daher in keinem Verlauf.

Natürlich ist das nicht wirklich so, aber für mich ist es ein schönes Modell. Und wenn Sie sich 2 und 3 ansehen, werden Sie verstehen, warum die Rollen jetzt vertauscht sind. Seit 2 ist Ihre derzeitige Zweigstelle die Zweigstelle vom Server, ohne dass Sie Änderungen vorgenommen haben. Dies ist also ours (der Zweig, in dem Sie sich befinden). Die Änderungen, die Sie vorgenommen haben, befinden sich jetzt in einem anderen Zweig, der nicht Ihr aktueller ist (BranchX). Daher sind diese Änderungen (auch wenn Sie Änderungen vorgenommen haben) ihre (der andere Zweig, der in Ihrer Aktion verwendet wird). .

Das bedeutet, wenn Sie zusammenführen und möchten, dass Ihre Änderungen immer gewinnen, würden Sie git sagen, dass Sie immer "unser" wählen sollen. Wenn Sie sich jedoch erneut abstimmen und alle Ihre Änderungen immer gewinnen möchten, sagen Sie git, dass Sie immer "ihre" wählen sollen.

1
Mecki

Aus der Verwendung von 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

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 Version bzw. die eingehenden Versionen 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-Merge-Version der Datei zurücksetzen möchten, können Sie git checkout --merge some_file ausführen. 

0
Joshua Ryan