Warum sollte ich eine Git-Rebase durchführen?

Ich habe viele Leute darüber sprechen sehen git rebase und was es tut, zB Hg: Wie man eine Rebase wie Gits Rebase macht und die Leute darüber reden, was es erreicht (gibt lineare Geschichte), zB hier verliert Git Rebase Geschichte, warum dann Rebase? Aber ich kann nicht nachvollziehen, warum du das tun willst.

Es scheint wie ein groß Kosten, um zurückzugehen und Ihren Commit-Verlauf zu überarbeiten (was sicherlich einige hässliche Zusammenführungen mit n-Wege-Konflikten beinhalten muss). Und ich könnte mir Fälle vorstellen, in denen es sehr irreführend sein könnte (z. B. wenn zwei Personen dasselbe Problem auf unterschiedliche Weise lösen, aber die Geschichte ihre Arbeit nicht als parallel aufgetreten anzeigt; das scheint auch leicht zu Kritik und Ressentiments führen zu können in manchen Hochdruck-Codierungsumgebungen).

Was Sie gewinnen, ist ein leichter verständliches, aber falsches Verlaufsdiagramm. Was macht den Aufwand wert?

Danke im Voraus.

Rebase ist am nützlichsten, wenn ein einzelner Commit oder eine kleine Anzahl von Commits, die in einem kurzen Zeitrahmen (Stunden oder Minuten) entwickelt wurden, gepusht werden.

Vor dem Pushen auf einen gemeinsam genutzten Server muss man zunächst die in der Zwischenzeit an den HEAD des Ursprungs vorgenommenen Commits abrufen – andernfalls würde ein nicht schneller Vorlauf-Push erzeugt. Dabei kann man wählen zwischen einer Zusammenführung (git pull) oder eine Rebase (git pull --rebase) Betrieb. Die Zusammenführungsoption ist zwar technisch ansprechender, erstellt jedoch ein zusätzliches Zusammenführungs-Commit. Bei einem kleinen Commit macht das Erscheinen von zwei Commits pro Änderung tatsächlich Geschichte weniger lesbar, da die Merge-Operation von der Botschaft des Commit ablenkt.

In einem typischen gemeinsam genutzten Entwicklungsbaum pusht jeder Entwickler zu einem gemeinsam genutzten Zweig, indem er eine Variation von ausführt git pull; <resolve conflicts>; git push. Wenn sie verwenden git pull ohne --rebasewas passiert, ist das fast jeder Commit schließlich von einem Merge-Commit begleitet wird, obwohl eigentlich keine parallele Entwicklung stattfand. Dadurch entsteht eine verflochtene Historie aus einer in Wirklichkeit linearen Abfolge von Commits. Deshalb, git pull --rebase ist eine bessere Option für kleine Änderungen, die sich aus einer kurzen Entwicklung ergeben, während ein Merge der Integration langlebiger Feature-Zweige vorbehalten ist.

All dies gilt für die Umbasierung lokal Commits oder Rebasing eines kurzlebigen Feature-Zweigs, der von eng verbundenen Kollegen (die im selben Raum sitzen) geteilt wird. Sobald ein Commit regelmäßig in einen Branch gepusht wird, gefolgt von anderen, sollte dies der Fall sein noch nie umbasiert werden.

Die Durchführung einer Rebase beinhaltet normalerweise nicht mehr Konfliktlösung als eine Zusammenführung, daher ist der Aufwand im Vergleich dazu minimal (eigentlich nur die Zeit, die zum erneuten Abspielen Ihrer Commits benötigt wird).

Wie bei den meisten Dingen, die mit Git zu tun haben, sollten Sie nur rebasen, wenn Sie es wissen was du tust, und warum du machst es. Hier sind einige meiner Gründe für das Rebasing:

• Ich habe an einer Patch-Serie gearbeitet, die keine Komponenten berührt hat, die zwischenzeitlich vom Upstream geändert wurden. Ein Merge-Commit würde in diesem Fall keine nützlichen Informationen enthalten.
• Ich bin dabei, einen Pull-Request auf zu senden GitHub, und der erforderliche Merge-Commit wäre eine Menge Arbeit. Indem ich zuerst rebasiere, mache ich die Pull-Anforderung für den Upstream-Eigentümer einfacher zu handhaben. Natürlich könnte ich stattdessen zusammenführen, aber da sie meinen Code noch nie zuvor gesehen haben, wird das die Patch-Serie nur schwerer lesbar machen.
• Ich führe Änderungen vom Upstream zusammen, und es gibt eine große Anzahl von Konflikten. git rebase ermöglicht es mir, diese Konflikte jeweils beim Festschreiben zu lösen, wodurch es einfacher wird, sie zu verstehen und zu testen, während ich gehe. Wenn es mir wichtig ist, einen Merge-Commit beizubehalten, kann ich danach einfach zu einer nicht rebasierten Version des Zweigs zurückkehren, ihn mit Upstream zusammenführen und dann das Diff gegen die rebasierte Version als Merge-Commit zur Konfliktlösung verwenden.

TLDR: Die Rebase-Strategie ist den Aufwand nicht wert.

Das einzige Nutzen der Rebase-Strategie ist eine lineare Geschichte und das war’s.

Stellen Sie sich jetzt die Frage, wie oft Sie den Git-Verlauf überprüft haben, um etwas herauszufinden? Könnten Sie es mit einer Merge-Strategie lösen?

Meine Antwort ist fast nie und ja, die Zusammenführungsstrategie ist nicht großartig, aber gut genug.

Aber hier kommt die kosten der Umbasierungsstrategie:

• Sie müssen Ihre Änderungen jedes Mal rebasen, wenn jemand anderes Änderungen an den Hauptzweig überträgt. Für 3 Entwickler ist es in Ordnung, aber für mehr wird es zu einem Problem. Fügen Sie hinzu, dass Sie darauf warten, dass eine Pipeline erstellt wird, und es wird zu einem Horror, irgendetwas zusammenzuführen.
• Sie können jeweils nur eine Änderung mit dem Hauptzweig “zusammenführen”, alle anderen müssen zuerst rebasiert und erneut per Pipeline erstellt werden (zusätzliche Verzögerung).
• Das Lösen von Konflikten muss für jeden Commit separat durchgeführt werden, das Lösen von Konflikten für ältere/veraltete Commits ist für mich verrückt, wenn ich weiß, dass ich es im nächsten Commit geändert habe.
• Wenn Sie Rebase vermasseln, würden Sie alle Fixes zum letzten Commit hinzufügen und alle älteren würden kaputt bleiben. Die Alternative ist, alles noch einmal von vorne zu beginnen.
• Sie müssen nach dem Rebase Push auf Ihren Zweig erzwingen, wenn Sie es vermasseln, verbringen Sie möglicherweise viele Stunden damit, Reflog zu scannen.
• Wenn Sie mehr als zwei Commits in Ihrem Zweig haben, quetschen Sie sie wahrscheinlich vor dem Rebase, um weniger Arbeit zu haben, und Sie verlieren Ihren wertvollen Commit-Verlauf.

Ich habe beides ausprobiert und wenn ich die Vorteile mit den Nachteilen vergleiche, ist die Rebase-Strategie keine Mühe wert.