Git - ist es Pull oder Rebase beim Arbeiten an Ästen mit anderen Menschen

Wenn ich also Zweige verwende, die entfernte (verfolgte) Zweige sind, und ich möchte die neuesten erhalten, bin ich immer noch unklar, ob ich git pull oder git rebase . Ich dachte, ich hätte gelesen, dass ich git rebase bei der Arbeit an einem Zweig mit anderen Benutzern mache, es kann sie beim Ziehen oder Rebase vermasseln. Ist das wahr? Sollten wir alle git pull verwenden?

0
hinzugefügt bearbeitet
Ansichten: 3

5 Antworten

Wenn Sie die Quelle ohne Auswirkungen auf Remote-Zweigstellen und ohne Änderungen in Ihrer lokalen Kopie abrufen möchten, empfiehlt es sich, git pull zu verwenden.

Ich glaube, wenn Sie einen funktionierenden Zweig haben, an dem Sie Änderungen vorgenommen haben, verwenden Sie git rebase, um die Basis dieses Zweiges als letzten Remote-Master zu ändern. Sie behalten alle Ihre Verzweigungsänderungen bei, verzweigen sich jedoch vom Master Standort, anstatt wo es vorher verzweigt wurde.

0
hinzugefügt

Git rebase ist eine Neuschreibung des Verlaufs. Sie sollten dies nie an Zweigen tun, die "öffentlich" sind (d. H. Zweige, die Sie mit anderen teilen). Wenn jemand Ihren Zweig klont und Sie dann diesen Zweig neu erstellen, dann können Sie keine Änderungen mehr aus Ihrem Zweig ziehen/zusammenführen. Sie müssen ihren alten wegwerfen und erneut ziehen.

Dieser Artikel über Paketierungssoftware mit git ist eine sehr lohnende Lektüre. Es geht mehr um die Verwaltung von Software-Distributionen, aber es ist ziemlich technisch und spricht darüber, wie Zweige verwendet/verwaltet/geteilt werden können. Sie reden darüber, wann und wann sie ziehen müssen und was die verschiedenen Folgen eines jeden sind.

Kurz gesagt, sie haben beide ihren Platz, aber Sie müssen wirklich den Unterschied machen.

0
hinzugefügt
Kurz gesagt, setzen Sie keine Commits neu, die in anderen Repositories existieren.
hinzugefügt der Autor Ikke, Quelle
Das Problem ist, wenn jemand anderes aus einem Zweig zieht, den Sie dann neu erstellen. Es ist in Ordnung, wenn ich von A in local dann local rebase und jemand anderes von A zieht. Es ist nicht in Ordnung, wenn ich von A ziehe, jemand anderes zieht von local , dann füge ich local hinzu.
hinzugefügt der Autor Cameron Skinner, Quelle
Ist das wahr, @Pat? Im Falle einer Pull - Rebase, sind Sie nicht gerade neu bestellen Sie Ihre lokalen Commits zu sein, über was Sie aus gezogen? Da dies lokale Commits waren und noch nicht veröffentlicht wurden, wie werden sie jemanden zerbrechen, der versucht, nachdem ich pull --rebase 'ed ziehen?
hinzugefügt der Autor Gabe Hollombe, Quelle

git pull does a merge if you've got commits that aren't in the remote branch. git rebase rewrites any existing commits you have to be relative to the tip of the remote branch. They're similar in that they can both cause conflicts, but I think using git rebase if you can allows for smoother collaboration. During the rebase operation you can refine your commits so they look like they were newly applied to the latest revision of the remote branch. A merge is perhaps more appropriate for longer development cycles on a branch that have more history.

Wie bei den meisten anderen Dingen in git gibt es viele überlappende Funktionen, die unterschiedlichen Arbeitsweisen gerecht werden.

0
hinzugefügt

Git Pull ist eine Kombination aus 2 Befehlen

  • git fetch (synchronisiert Ihren lokalen Repo mit den neuesten Dateien auf der Fernbedienung)
  • git merge (fügt die Änderungen aus dem entfernten Zweig, falls vorhanden, in Ihren lokalen Verfolgungszweig ein)

git rebase ist nur eine grobe Entsprechung zu git merge. Es holt nichts aus der Ferne. Tatsächlich führt es auch keine richtige Zusammenführung durch, es wiederholt die Commits des Zweiges, auf dem Sie stehen, nach den neuen Commits von einem zweiten Zweig.

Sein Zweck ist hauptsächlich, Ihnen eine sauberere Geschichte zu lassen. Es braucht nicht viele Zusammenführungen von vielen Menschen, bevor die Vergangenheit in Gitk schrecklich Spaghetti-ähnlich wird.

Die beste grafische Erklärung findet sich in den ersten beiden Grafiken: hier . Aber lassen Sie mich hier mit einem Beispiel erklären.

Ich habe 2 Zweige: Master und Mybranch. Wenn ich auf meinem Bauch stehe, kann ich rennen

git rebase master

und ich werde etwas neues in master bekommen, das vor meinen letzten commits in mybranch eingefügt wurde. Das ist perfekt, denn wenn ich nun das Material von mybranch in master fusioniere oder neu bette, werden meine neuen Commits linear nach den letzten Commits hinzugefügt.

Das Problem, auf das du dich beziehst, passiert, wenn ich in die "falsche" Richtung rebase. Wenn ich gerade den letzten Master (mit neuen Änderungen) bekommen habe und von Master habe ich das wie folgt gemacht (bevor ich meinen Zweig synchronisiere):

git rebase mybranch

Nun, was ich gerade getan habe ist, dass ich meine neuen Änderungen irgendwo in der Vergangenheit des Meisters eingefügt habe. Die Hauptlinie der Commits hat sich geändert. Und aufgrund der Art, wie Git mit Commit-IDs arbeitet, haben alle Commits (vom Master), die gerade über meine neuen Änderungen wiedergegeben wurden, neue IDs.

Nun, es ist ein bisschen schwer zu erklären, nur mit Worten ... Hoffe, das macht ein bisschen Sinn :-)

Jedenfalls ist mein eigener Workflow das:

  • 'git pull' neue Änderungen von Remote
  • zu mybranch wechseln
  • 'git rebase master', um die neuen Änderungen des Masters in meinen Commit-Verlauf zu bringen
  • wechsle zurück zum Master
  • 'git merge mybranch', das nur dann vorspult, wenn alles im Master auch in mybranch ist (wodurch das Commit-Reordering-Problem in einer öffentlichen Verzweigung vermieden wird)
  • 'git push'

Ein letztes Wort. Ich empfehle dringend, Rebase zu verwenden, wenn die Unterschiede trivial sind (z. B. Leute, die an verschiedenen Dateien oder mindestens verschiedenen Zeilen arbeiten). Es hat das Problem, dass ich versucht habe, es zu erklären, aber es macht eine viel sauberere Geschichte.

Sobald es zu erheblichen Konflikten kommen kann (z. B. hat ein Kollege etwas in einer Reihe von Dateien umbenannt), empfehle ich dringend die Zusammenführung. In diesem Fall werden Sie aufgefordert, den Konflikt zu lösen und dann die Lösung zu bestätigen. Auf der positiven Seite ist eine Zusammenführung viel einfacher zu lösen, wenn Konflikte auftreten. Der Nachteil ist, dass Ihre Geschichte schwer zu folgen ist, wenn viele Leute die ganze Zeit zusammen kommen :-)

Viel Glück!

0
hinzugefügt
Es scheint mir, dass Sie gesagt haben sollten: 'git merge mybranch', das nur vorspult, wenn alles in master auch in mybranch ist (wodurch das Commit-reordering-Problem in einer öffentlichen Filiale vermieden wird)
hinzugefügt der Autor Bruno Bronosky, Quelle
'git rebase mybranch' sollte unbedingt 'git merge mybranch' lesen.
hinzugefügt der Autor James H, Quelle

Sehen Sie sich die ausgezeichneten Gitcasts auf Verzweigen und Zusammenführen an sowie Rebasing .

0
hinzugefügt