Git-Zweige von Master aktualisieren

Question

Ich bin neu bei Git, und jetzt bin ich in dieser Situation:

• Ich habe vier Zweige (master, b1, b2 und b3).
• Nachdem ich an b1-b3 gearbeitet hatte, wurde mir klar, dass ich im Zweig master etwas ändern muss, das in allen anderen Zweigen vorhanden sein sollte.
• Ich habe geändert, was ich brauchte in master und... hier ist mein Problem:

Wie aktualisiere ich alle anderen Zweige mit master Verzweigungscode?

Answer 1

Sie haben zwei Möglichkeiten:

Die erste ist eine Zusammenführung, die jedoch einen zusätzlichen Commit für die Zusammenführung erzeugt.

Prüfen Sie jede Filiale:

git checkout b1

Dann fusionieren:

git merge origin/master

Dann drücken Sie:

git push origin b1

Alternativ können Sie auch einen Re-Base durchführen:

git fetch
git rebase origin/master

Answer 2

Sie haben grundsätzlich zwei Möglichkeiten:

1. Sie verschmelzen. Das ist eigentlich ganz einfach, und ein vollkommen lokaler Vorgang:

   git checkout b1
   git merge master
   # repeat for b2 and b3

   Damit bleibt die Geschichte genau so, wie sie war: Sie haben sich von master gegabelt, Sie haben Änderungen an allen Zweigen vorgenommen und schließlich die Änderungen von master in alle drei Zweige integriert.

   git kann mit dieser Situation sehr gut umgehen, da es für Zusammenführungen in alle Richtungen gleichzeitig ausgelegt ist. Sie können sich darauf verlassen, dass es alle Fäden korrekt zusammenführt. Es kümmert sich einfach nicht darum, ob ein Zweig b1 verschmilzt master o master verschmilzt b1 sieht der Merge-Commit für Git ganz gleich aus. Der einzige Unterschied besteht darin, welcher Zweig am Ende auf diesen Merge Commit verweist.

2. Sie rebasen. Leute mit einem SVN- oder ähnlichen Hintergrund finden dies intuitiver. Die Befehle sind analog zum Merge-Fall:

   git checkout b1
   git rebase master
   # repeat for b2 and b3

   Dieser Ansatz ist beliebt, weil er eine lineare Geschichte in allen Zweigen beibehält. Diese lineare Historie ist jedoch eine Lüge, und Sie sollten sich dessen bewusst sein, dass sie es ist. Betrachten Sie diesen Commit-Graphen:

   A --- B --- C --- D <-- master
    \
     \-- E --- F --- G <-- b1

   Die Verschmelzung ergibt die wahre Geschichte:

   A --- B --- C --- D <-- master
    \                 \
     \-- E --- F --- G +-- H <-- b1

   Mit der Rebase erhalten Sie jedoch diese Geschichte:

   A --- B --- C --- D <-- master
                      \
                       \-- E' --- F' --- G' <-- b1

   Der Punkt ist, dass die Übertragungen E' , F' y G' nie wirklich existiert haben und wahrscheinlich auch nie getestet wurden. Möglicherweise lassen sie sich nicht einmal kompilieren. Es ist eigentlich ziemlich einfach, unsinnige Commits über eine Rebase zu erstellen, besonders wenn die Änderungen in master sind wichtig für die Entwicklung in b1 .

   Dies kann zur Folge haben, dass Sie nicht unterscheiden können, welche der drei Übertragungen E , F y G tatsächlich eine Regression eingeführt, die den Wert von git bisect .

   Ich will damit nicht sagen, dass Sie nicht git rebase . Es hat seinen Nutzen. Aber wann immer Sie es verwenden, müssen Sie sich der Tatsache bewusst sein, dass Sie über die Geschichte lügen. Und Sie sollten die neuen Übertragungen zumindest kompilieren und testen.

Answer 3

git rebase master ist der richtige Weg, dies zu tun. Das Zusammenführen würde bedeuten, dass ein Commit für das Zusammenführen erstellt wird, während das Umbasieren nicht erfolgt.

Answer 4

Wenn Sie an einem Zweig immer wieder gearbeitet haben, oder sich in anderen Zweigen viel getan hat, während Sie an etwas gearbeitet haben, ist es am besten, wenn Sie Ihren Zweig auf den Master-Zweig umbinden. Das hält die Historie ordentlich und macht die Dinge viel einfacher zu verfolgen.

git checkout master
git pull
git checkout local_branch_name
git rebase master
git push --force # force required if you've already pushed

Notes :

• Verschieben Sie keine Zweige, an denen Sie mit anderen zusammengearbeitet haben.
• Sie sollten auf dem Zweig rebasen, auf den Sie zusammenführen werden, was nicht immer der Master-Zweig sein muss.

Es gibt ein Kapitel über Umbasierung unter http://git-scm.com/book/ch3-6.html und viele andere Ressourcen im Internet.

Answer 5

@cmaster hat die am besten ausgearbeitete Antwort gegeben. Kurz und gut:

git checkout master #
git pull # update local master from remote master
git checkout <your_branch>
git merge master # solve merge conflicts if you have`

Sie sollten die Zweighistorie nicht umschreiben, sondern den aktuellen Zustand für zukünftige Referenzen beibehalten. Beim Zusammenführen zum Master wird ein zusätzlicher Commit erzeugt, aber das ist billig. Commits kosten nicht.