Rebase vs. Merge: Integration von Änderungen in Git

Dieser Artikel setzt unsere "Advanced Git" -Serie fort. Folgen Sie uns auf Twitter oder abonnieren Sie unseren Newsletter, um Updates zu zukünftigen Artikeln zu erhalten!

Eine effektive Git -Verzweigung ist für Entwickler von entscheidender Bedeutung. In meinem vorherigen Artikel detaillierten Verzweigungsstrategien, Git -Zweigmodell, Zweigarten und gemeinsame Workflows. Der Kernvorteil: Isolierte Arbeitsbereiche (Zweige) verbessern die Versionskontrolle erheblich.

Dieser Artikel konzentriert sich auf die Integration von Zweigen - effizientes Zusammenführen von Code in die Hauptentwicklungslinie. Wir werden zwei wichtige Methoden untersuchen: Zusammenführen und Wiedergeburt.

Sowohl git merge als auch git rebase lösen das gleiche Problem: Integration von Änderungen von einem Zweig in einen anderen. Ihre Ansätze unterscheiden sich jedoch erheblich. Lassen Sie uns zuerst das Zusammenführen untersuchen.

Erweiterte Git -Serie:

• Teil 1: Erstellen des idealen Git -Commits
• Teil 2: Optimierung der Git -Verzweigungsstrategien
• Teil 3: Straffung der Zusammenarbeit mit Pull -Anfragen
• Teil 4: Lösung von Zusammenführungskonflikten effektiv
• Teil 5: Rebase vs. Merge ( Sie sind hier! )
• Teil 6: Mastering Interactive Rebase
• Teil 7: Cherry-Picking Commits in Git
• Teil 8: Verwenden des Reflogs, um verlorene Commits wiederzugewinnen

Gitverständnis zu verstehen

Der Befehl git merge integriert Zweige. Stellen Sie sich branch-B mit neuen Commits vor; sich in branch-A zusammenschließen:

 <code>$ git checkout branch-A $ git merge branch-B</code>

Dies schafft einen neuen Merge-Commit für branch-A und verbindet beide Branchengeschichten. Git identifiziert drei Schlüssel Commits:

• Der gemeinsame Vorfahr: Der Punkt, an dem beide Zweige den identischen Code vor dem Divergieren teilten.
• Die Zweigendpunkte: Die neuesten Commits in jedem Zweig, der ihre aktuellen Zustände darstellt.

Git kombiniert diese Commits, um eine Integration zu erreichen. Ein vereinfachtes Szenario (in dem branch-A seit der Verzweigung keine Commits hat) führt zu einer "schnellen Vorwärts" -Guschinen-effizientes Hinzufügen branch-B -Commits direkt.

In den meisten realen Szenarien haben sich beide Zweige unabhängig voneinander entwickelt. Git schafft dann einen Merge-Engagement , um die Änderungen zu kombinieren, ein eigenes Commit, das automatisch generiert wird, im Gegensatz zu Entwicklern geschaffenen Commits. Das Verständnis dieser automatischen Zusammenführung erfordert die Analyse der vollständigen Zweighistorien.

Menschlicher vs. merge Commits

Entwickler geschaffene Commits sind sorgfältig strukturiert und enthalten verwandte Änderungen und informative Nachrichten. Merge -Commits verbinden umgekehrt automatisch Filialen und stellen nicht unbedingt einen semantisch kohärenten Satz von Änderungen dar.

Integration in das Wiedergeburt

Das Wiedergeburt bietet eine Alternative zum Zusammenführen. Es ist nicht von Natur aus "besser", einfach anders. Sie können Git ausschließlich mit Verschmelzung erfolgreich verwalten. Das Verständnis des Wiedergeburtes bietet jedoch wertvolle Optionen.

Das Wiedergeburten vermeidet automatische Verschmelzungs -Commits, wodurch eine lineare Projekthistorie geschaffen wird, wodurch die Divergenz -Spuren von Zweigbildern beseitigt wird.

Wiedergeburt: eine Schritt-für-Schritt-Anleitung

Lassen Sie uns branch-B in branch-A wiederholen:

 <code>$ git checkout branch-A $ git rebase branch-B</code>

Der Prozess umfasst drei Schritte:

1. Vorübergehend Entfernen von Commits: Commits in branch-A nachdem der gemeinsame Vorfahren vorübergehend gespeichert wurde.
2. Anwendung der Commits von branch-B : Die Commits von branch-B werden angewendet, wodurch beide Zweige vorübergehend ausgerichtet sind.
3. Rebasing branch-A -Commits: Die vorübergehend gespeicherten branch-A Commits werden auf den Commits von branch-B erneut angewendet, wodurch eine lineare Geschichte geschaffen wird.

Das Ergebnis: Eine optimierte Geschichte ohne Verschmelzung.

Potenzielle Fallstricke von Neubasing wieder aufbauen

Entscheidend, dass neu das Wiederaufschreiben von Umschreibungen bestritt. Während der Inhalt gleich bleibt, ändert sich die übergeordneten Eltern des Commits und generieren einen neuen SHA-1-Hash.

Dies ist für unveröffentlichte Commits akzeptabel. Rebasing veröffentlichte Commits ist jedoch riskant und stört möglicherweise Mitarbeiter, die ihre Arbeiten auf den ursprünglichen Commits basieren.

Die goldene Regel: Niemals öffentliche Zweige wiederherstellen! Verwenden Sie die Wiederherstellung lokal, um Ihre Geschichte zu beseitigen, bevor Sie in gemeinsame Zweige integriert werden.

Integrationsstrategien: Zusammenführen gegen Rebase

Zusammenführung und Wiedergeburt sind beide wertvolle Werkzeuge. Das Zusammenführen bewahrt die Geschichte nicht-zerstörend. Wiederherstellung der Stromliniengeschichte, erfordert jedoch Vorsicht in Bezug auf veröffentlichte Commits.

Entdecken Sie mein kostenloses "Advanced Git Kit" für tiefere Einblicke in Git -Tools.

Viel Spaß beim Zusammenführen und Wiedergeburt! Wir sehen uns in der nächsten "Advanced Git" -Angabe!

Erweiterte Git -Serie:

• Teil 1: Erstellen des idealen Git -Commits
• Teil 2: Optimierung der Git -Verzweigungsstrategien
• Teil 3: Straffung der Zusammenarbeit mit Pull -Anfragen
• Teil 4: Lösung von Zusammenführungskonflikten effektiv
• Teil 5: Rebase vs. Merge ( Sie sind hier! )
• Teil 6: Mastering Interactive Rebase
• Teil 7: Cherry-Picking Commits in Git
• Teil 8: Verwenden des Reflogs, um verlorene Commits wiederzugewinnen

Das obige ist der detaillierte Inhalt vonRebase vs. Merge: Integration von Änderungen in Git. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!