Ein neuer Zweig von master
wird erstellt, wir nennen ihn test
.
Es gibt mehrere Entwickler, die sich entweder an master
binden oder andere Zweige erstellen und später in master
zusammenführen.
Nehmen wir an, die Arbeit an test
dauert mehrere Tage und Sie wollen test
kontinuierlich mit Commits innerhalb von master
auf dem neuesten Stand halten.
Ich würde git pull origin master
von test
ausführen.
Frage 1: Ist dies der richtige Ansatz? Andere Entwickler hätten leicht an denselben Dateien arbeiten können, wie ich es übrigens getan habe.
Meine Arbeit an test
ist abgeschlossen und ich bin bereit, sie wieder in master
einzubinden. Hier sind die zwei Möglichkeiten, die ich mir vorstellen kann:
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 verwende --rebase
nicht, weil rebase meines Erachtens die Änderungen von master
übernimmt und meine darauf stapelt, so dass es die Änderungen anderer Leute überschreiben könnte.
Frage 2: Welche dieser beiden Methoden ist richtig? Worin besteht der Unterschied?
Das Ziel bei all dem ist es, meinen "test"-Zweig mit den Dingen, die im "master"-Zweig passieren, auf dem neuesten Stand zu halten, und später könnte ich sie wieder in den "master"-Zweig einfügen, in der Hoffnung, die Zeitlinie so linear wie möglich zu halten.
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 möchte, zufrieden bin, und ich würde auch überhaupt keine Dinge pushen, die nur für mich und mein lokales Repository bestimmt sind. In Ihrer Beschreibung scheint es so, als ob test
nur für Sie ist? Also kein Grund, es zu veröffentlichen.
git versucht immer, deine und andere Änderungen zu respektieren, und so wird auch --rebase
. Ich glaube nicht, dass ich es angemessen erklären kann, also schau dir the Git book - Rebasing oder git-ready: Intro into rebasing für eine kleine Beschreibung an. Es ist eine ziemlich coole Funktion
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 Probleme:
Es ist unsicher, weil wir nicht wissen, ob es irgendwelche Konflikte zwischen dem Testzweig und dem Masterzweig gibt.
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
Testen Sie merge
vor commit
, vermeiden Sie einen Fast-Forward-Commit durch --no-ff
,
Wenn ein Konflikt auftritt, können wir git status
ausführen, 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, commit
und push
sie
git commit -m 'merge test branch'
git push
Auf diese Weise gehen jedoch die im Testzweig protokollierten Änderungen verloren, und es wäre für andere Entwickler schwierig, den Verlauf des Projekts zu verstehen.
Die beste Methode ist also die Verwendung von rebase
anstelle von merge
(angenommen, wir haben zu diesem Zeitpunkt die Zweigkonflikte gelöst).
Nachfolgend ein einfaches Beispiel, für fortgeschrittene Operationen schauen Sie bitte auf 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 die Uppers durchgeführt haben, werden alle Commits des Test-Zweiges in den Kopf des Master-Zweiges verschoben. Der Hauptvorteil des Rebasings ist, dass Sie einen linearen und viel saubereren Projektverlauf erhalten.
Die einzige Sache, die Sie vermeiden müssen, ist: Verwenden Sie niemals rebase
auf einem öffentlichen Zweig, wie dem Master-Zweig.
Niemals Operationen wie die folgenden durchführen:
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:
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, zurück in Master zu mergen,
git checkout master
git log ..test # if you're curious
git merge test
git push
Wenn Sie sich Sorgen machen, etwas beim Zusammenführen kaputt zu machen, ist git merge --abort
für Sie da.
Push und dann Pull als Mittel zum Zusammenführen zu benutzen ist dumm. Ich bin mir auch nicht sicher, warum Sie test nach origin pushen.