Wie führe ich einen Git-Zweig sicher in Master zusammen?

Question

Ein neuer Zweig von master erstellt wird, nennen wir es test .

Es gibt mehrere Entwickler, die sich entweder zu master oder andere Zweige erstellen und später in master .

Sagen wir, die Arbeit an test mehrere Tage in Anspruch nimmt und Sie möchten kontinuierlich die test aktualisiert mit Übertragungen innerhalb master .

Ich würde tun git pull origin master de test .

Frage 1: Ist dies der richtige Ansatz? Andere Entwickler hätten leicht an denselben Dateien arbeiten können, an denen ich gearbeitet habe.

---

Meine Arbeit an test ist fertig und ich bin bereit, sie wieder mit master . Hier sind die beiden Möglichkeiten, die mir einfallen:

A:

git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test 

B:

git checkout test
git pull origin master
git checkout master
git merge test

Ich benutze nicht --rebase denn nach meinem Verständnis erhält rebase die Änderungen von master und stapeln meine darüber, so dass sie die Änderungen anderer Leute überschreiben könnte.

Frage 2: Welche dieser beiden Methoden ist die richtige? Worin besteht der Unterschied?

Das Ziel dabei ist es, meine test Zweigstelle über die Geschehnisse in der master und später könnte ich sie wieder in master in der Hoffnung, die Zeitachse so linear wie möglich zu halten.

Answer 1

Wie ich das machen würde

git checkout master
git pull origin master
git merge test
git push origin master

Wenn ich einen lokalen Zweig von einem entfernten Zweig habe, fühle ich mich nicht wohl dabei, andere Zweige als diesen mit dem entfernten Zweig zusammenzuführen. Außerdem würde ich meine Änderungen erst dann pushen, wenn ich mit dem, was ich pushen will, zufrieden bin, und auch Dinge, die nur für mich und mein lokales Repository bestimmt sind, würde ich gar nicht pushen. In Ihrer Beschreibung scheint es, dass test ist nur für Sie? Also kein Grund, es zu veröffentlichen.

git versucht immer, Ihre und andere Änderungen zu respektieren, und so wird --rebase . Ich glaube nicht, dass ich es angemessen erklären kann, also sehen Sie sich das an das Git-Buch - Neuausrichtung o git-ready: Einführung in das Rebasing für eine kleine Beschreibung. Es ist eine ziemlich coole Funktion

Answer 2

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

Wie

git checkout master
git pull origin master
git merge test
git push origin master

Dieser Ansatz hat zwei Themen :

1. Das ist unsicher, denn wir wissen nicht, ob es Konflikte zwischen dem Testzweig und dem Masterzweig gibt.

2. Es würde alle Test-Commits in einen Merge-Commit auf dem Master-Zweig "quetschen"; d.h. auf dem Master-Zweig können wir nicht alle Änderungsprotokolle des Test-Zweigs sehen.

Wenn wir also vermuten, dass es Konflikte gibt, können wir folgende Git-Operationen durchführen:

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

Test merge avant commit vermeiden Sie einen Fast-Forward-Commit durch --no-ff ,

Wenn ein Konflikt auftritt, können wir Folgendes ausführen git status um Details über die Konflikte zu prüfen und zu versuchen, sie zu lösen

git status

Sobald wir die Konflikte gelöst haben, oder wenn es keinen Konflikt gibt, werden wir commit y push sie

git commit -m 'merge test branch'
git push

Auf diese Weise geht jedoch die im Testzweig protokollierte Änderungshistorie verloren, und es würde den Masterzweig für andere Entwickler schwer machen, die Geschichte des Projekts zu verstehen.

Die beste Methode ist also die Verwendung von rebase anstelle von merge (Nehmen wir an, dass wir in dieser Zeit die Zweigkonflikte gelöst haben).

Im Folgenden finden Sie ein einfaches Beispiel, für fortgeschrittene Operationen lesen Sie bitte 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 die Uppers fertig sind, werden alle Commits des Testzweigs auf den Kopf des Masterzweigs verschoben. Der Hauptvorteil des Rebasings ist, dass Sie einen linearen und viel saubereren Projektverlauf erhalten.

Das Einzige, was Sie vermeiden müssen, ist: Verwenden Sie niemals rebase auf dem öffentlichen Zweig, wie dem Master-Zweig.

Niemals Operationen durchführen wie die folgenden:

git checkout master
git rebase -i test

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

Anhang:

• Wenn Sie sich nicht sicher sind, wie die Umbasierung funktioniert, lesen Sie bitte nach: https://git-scm.com/book/en/v2/Git-Branching-Rebasing

Answer 3

Weder ein Rebase noch ein Merge sollte die Änderungen anderer überschreiben (es sei denn, Sie entscheiden sich dafür, wenn Sie einen Konflikt auflösen).

Die übliche Vorgehensweise 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, dass Sie bei der Zusammenführung etwas kaputt machen könnten, git merge --abort ist für Sie da.

Push und dann Pull als Mittel zur Verschmelzung zu verwenden, ist albern. Ich bin mir auch nicht sicher, warum Sie den Test zum Ursprung schieben.

Answer 4

Ich würde zunächst den zu fusionierenden Zweig so sauber wie möglich machen. Führen Sie Ihre Tests durch und stellen Sie sicher, dass der Zustand so ist, wie Sie ihn haben wollen. Bereinigen Sie die neuen Übertragungen durch Quetschkommode .

Neben KingCrunches Antwort schlage ich vor, Folgendes zu verwenden

git checkout master
git pull origin master
git merge --squash test
git commit
git push origin master

Möglicherweise haben Sie im anderen Zweig viele Übertragungen vorgenommen, die im Master-Zweig nur eine einzige sein sollten. Um die Commit-Historie so sauber wie möglich zu halten, möchten Sie vielleicht alle Ihre Commits aus dem Testzweig in einen Commit im Masterzweig zusammenfassen (siehe auch: Git: Quetschen oder nicht quetschen? ). Dann können Sie auch die Commit-Nachricht in etwas sehr Aussagekräftiges umschreiben. Etwas, das leicht zu lesen und zu verstehen ist, ohne sich in den Code zu vertiefen.

edit: Das könnte Sie interessieren

• Was ist in Git der Unterschied zwischen merge --squash und rebase?
• Zusammenführung vs. Neusortierung
• Wie man eine Pull-Anfrage neu basiert

Auf GitHub muss ich also für einen Feature-Zweig Folgendes tun mybranch :

Erhalten Sie das Neueste vom Ursprung

$ git checkout master
$ git pull origin master

Finden Sie den Merge-Basis-Hash:

$ git merge-base mybranch master
c193ea5e11f5699ae1f58b5b7029d1097395196f

$ git checkout mybranch
$ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f

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

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

Als Nächstes wählen Sie eine sehr gute Commit-Nachricht und pushen sie auf GitHub. Stellen Sie dann die Pull-Anfrage.

Nach der Zusammenführung der Pull-Anfrage können Sie diese lokal löschen:

$ git branch -d mybranch

und auf GitHub

$ git push origin :mybranch

Answer 5

Alter Thread, aber ich habe nicht gefunden meine Art es zu tun. Es könnte für jemanden wertvoll sein, der mit Rebase arbeitet und alle Commits aus einem (Feature-)Zweig über Master zusammenführen möchte. Wenn es unterwegs einen Konflikt gibt, kann man ihn für jeden Commit auflösen. Sie behalten während des Prozesses die volle Kontrolle und können jederzeit abbrechen.

Aktualisieren Sie Master und Branch:

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

Zweig über dem Master zusammenführen:

git checkout <branch_name>
git rebase master

Optional: Wenn Sie während der Neuinstallation auf Konflikte stoßen:

Lösen Sie zunächst den Konflikt in der Datei. Dann:

git add .
git rebase --continue

Sie können die Umbasierung jederzeit mit abbrechen:

git rebase --abort

Schieben Sie Ihre neu erstellte Verzweigung:

git push origin <branch_name>

Wenn Sie diesen Zweig bereits gepusht haben, müssen Sie ihn mit einem Force Push überschreiben:

git push origin -f <branch_name>

Prüfen Sie vorher immer, ob Ihr aktueller lokaler Zweig Ihren Erwartungen entspricht, denn der Force Push überschreibt den alten Zweig im entfernten Repository.

Jetzt haben Sie zwei Möglichkeiten:

• A) Erstellen Sie einen PR (z.B. auf GitHub) und führen Sie ihn dort über die Benutzeroberfläche zusammen

• B) Gehen Sie zurück auf die Kommandozeile und führen Sie den Zweig in Master zusammen

  git checkout master git merge --no-ff <branch_name> git push origin master

Erledigt.