Was ist der beste (und sicherste) Weg, eine Git-Verzweigung in master zusammenzuführen?

Dies ist eine sehr praktische Frage, aber alle obigen Antworten sind nicht praktisch.

Mögen

git checkout master
git pull Origin master
git merge test
git Push Origin master

Dieser Ansatz hat zwei Probleme :

1. Es ist unsicher, da wir nicht wissen, ob es Konflikte zwischen Testzweig und Masterzweig gibt.

2. Es würde alle Test-Commits zu einem Merge-Commit für den Master zusammenfassen. Das heißt, auf dem Hauptzweig werden nicht alle Änderungsprotokolle des Testzweigs angezeigt.

Wenn wir also vermuten, dass es zu Konflikten kommt, können wir folgende Git-Operationen ausführen:

git checkout test
git pull 
git checkout master
git pull
git merge --no-ff --no-commit test

Testen Sie merge vor commit, vermeiden Sie ein Fast-Forward-Commit von --no-ff,

Wenn ein Konflikt auftritt, können wir git status ausführen, um Details zu den Konflikten zu überprüfen und zu lösen

git status

Sobald wir die Konflikte gelöst haben oder wenn es keinen Konflikt gibt, commit und Push

git commit -m 'merge test branch'
git Push

Auf diese Weise geht jedoch der im Testzweig protokollierte Änderungsverlauf verloren, und es würde für andere Entwickler schwierig werden, den Verlauf des Projekts zu verstehen.

Die beste Methode ist also, rebase anstelle von merge zu verwenden (nehmen wir an, wir haben in dieser Zeit die Verzweigungskonflikte gelöst).

Im Folgenden finden Sie ein einfaches Beispiel für erweiterte Funktionen: http://git-scm.com/book/en/v2/Git-Branching-Rebasing

git checkout master
git pull
git checkout test
git pull
git rebase -i master
git checkout master
git merge test

Ja, wenn Sie das Obermaterial fertig haben, werden alle Festschreibungen des Testzweigs auf den Kopf des Masterzweigs verschoben. Der Hauptvorteil des Neu-Basierens ist, dass Sie einen linearen und viel saubereren Projektverlauf erhalten.

Das einzige, was Sie vermeiden müssen, ist: Verwenden Sie rebase niemals für öffentliche Zweige, wie Master-Zweige.

Führen Sie niemals Operationen wie die folgenden aus:

git checkout master
git rebase -i test

Details für https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing

blinddarm:

• wenn Sie sich nicht sicher sind, wie Sie die Basis neu konfigurieren sollen, lesen Sie bitte: https://git-scm.com/book/en/v2/Git-Branching-Rebasing

Weder eine Neufassung noch eine Zusammenführung sollten die Änderungen einer Person überschreiben (es sei denn, Sie möchten dies bei der Lösung eines Konflikts tun).

Der übliche Ansatz bei der Entwicklung ist

git checkout master
git pull
git checkout test
git log master.. # if you're curious
git merge Origin/test # to update your local test from the fetch in the pull earlier

Wenn Sie bereit sind, wieder in Master zusammenzuführen,

git checkout master
git log ..test # if you're curious
git merge test
git Push

Wenn Sie sich Sorgen machen, etwas bei der Zusammenführung zu brechen, ist git merge --abort für Sie da.

Push und dann Pull als Mittel zum Zusammenführen zu verwenden, ist albern. Ich bin mir auch nicht sicher, warum Sie den Test an Origin weiterleiten.

Ich würde zuerst die zu verschmelzende Filiale so sauber wie möglich machen. Führen Sie Ihre Tests durch, und stellen Sie sicher, dass der Status Ihren Wünschen entspricht. Bereinige die neuen Commits mit Git Squash .

Neben KingCrunches-Antwort schlage ich vor, zu verwenden

git checkout master
git pull Origin master
git merge --squash test
git commit
git Push Origin master

Möglicherweise haben Sie in der anderen Verzweigung viele Festschreibungen vorgenommen. Dies sollte nur eine Festschreibung in der Master-Verzweigung sein. Um den Festschreibungsverlauf so sauber wie möglich zu halten, möchten Sie möglicherweise alle Festschreibungen aus dem Testzweig in einem Festschreibungszweig im Masterzweig zusammenfassen (siehe auch: Git: Quetschen oder nicht quetschen? ) . Dann können Sie die Commit-Nachricht auch in etwas sehr Ausdrucksvolles umschreiben. Etwas, das leicht zu lesen und zu verstehen ist, ohne sich in den Code einzuarbeiten.

edit: Das könnte dich interessieren

• Was ist in git der Unterschied zwischen merge --squash und rebase?
• Zusammenführen vs. Wiederholen
• Wiederherstellen einer Pull-Anforderung

Also mache ich auf GitHub Folgendes für einen Feature-Zweig mybranch:

Holen Sie sich das Neueste von Origin

$ git checkout master
$ git pull Origin master

Finden Sie den Merge Base Hash:

$ git merge-base mybranch master
c193ea5e11f5699ae1f58b5b7029d1097395196f

$ git checkout mybranch
$ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f

Stellen Sie nun sicher, dass nur das erste pick ist, der Rest ist s:

pick 00f1e76 Add first draft of the Pflichtenheft
s d1c84b6 Update to two class problem
s 7486cd8 Explain steps better

Wählen Sie als nächstes eine sehr gute Commit-Nachricht und Push to GitHub. Machen Sie dann die Pull-Anfrage.

Nach dem Zusammenführen der Pull-Anforderung können Sie diese lokal löschen:

$ git branch -d mybranch

und auf GitHub

$ git Push Origin :mybranch

Dies ist der Workflow, den ich bei meiner Arbeit im Team verwende. Das Szenario ist so, wie Sie es beschrieben haben. Erstens, wenn ich mit der Arbeit an test fertig bin, wende ich mich an den Master, um alles, was in der Zeit, in der ich an dem Zweig test gearbeitet habe, zum Master hinzugefügt wurde.

git pull -r upstream master

Dadurch werden die Änderungen in den Master übernommen, seitdem Sie den Zweig test geöffnet und angewendet haben. Anschließend werden die Änderungen angewendet, die Sie vorgenommen haben, um den aktuellen Master-Status "über" zu testen. Hier kann es zu Konflikten kommen, wenn die anderen Personen Änderungen an denselben Dateien vorgenommen haben, die Sie im Test bearbeitet haben. Wenn dies der Fall ist, müssen Sie sie manuell reparieren und festschreiben. Sobald Sie dies getan haben, können Sie problemlos zum Hauptzweig wechseln und test zusammenführen.

Alter Thread, aber ich habe meinen Weg nicht gefunden. Dies kann für jemanden von Nutzen sein, der mit Rebase arbeitet und alle Commits aus einem Zweig auf Master zusammenführen möchte. Wenn es unterwegs zu einem Konflikt kommt, können Sie diesen für jedes Commit lösen.

Master und Branch auf den neuesten Stand bringen:

git checkout master
git pull --rebase Origin master
git checkout <branch_name>
git pull --rebase Origin <branch_name>

Zweig auf Master zusammenfassen:

git checkout <branch_name>
git rebase master

Wenn Sie während des Neustarts auf Konflikte stoßen:

Beheben Sie zunächst den Konflikt in der Datei. Dann:

git add .
git rebase --continue

Nach Abschluss der Wiederherstellung wird der Zweig auf dem Master wiederhergestellt:

git checkout master
git rebase <branch_name>

Ich würde die Rebase-Methode verwenden. Meistens, weil es Ihren Fall semantisch perfekt widerspiegelt, d. H. Sie möchten lediglich den Status Ihres aktuellen Zweigs aktualisieren und so tun, als ob er auf dem neuesten basiert.

Ohne master auszuprobieren, würde ich:

git fetch Origin
git rebase -i Origin/master
# ...solve possible conflicts here

Natürlich wird durch das Abrufen von Origin der lokale Status von master nicht aktualisiert (da keine Zusammenführung durchgeführt wird), aber für unsere Zwecke ist dies vollkommen in Ordnung - wir möchten das Umschalten aus Gründen der Sicherheit vermeiden Zeit sparen.

git checkout master
git pull Origin master
# Merge branch test into master
git merge test

Wenn die Datei nach dem Zusammenführen geändert wird, tritt beim Zusammenführen der Fehler "Konflikt lösen" auf.

Dann müssen Sie zuerst alle Ihre Konflikte lösen, dann müssen Sie alle Ihre Änderungen erneut festschreiben und dann Push

git Push Origin master

Dies ist besser, wenn Sie Änderungen im Testzweig vorgenommen haben, da Sie wissen, welche Änderungen Sie vorgenommen haben.