2017-02-28 1 views
0

Ein Argument gegen git rebase könnte sein, dass es einen komplexeren Prozess als merge ist, und wenn mehrere Entwickler einen Feature-Zweig teilen, bedeutet Midstream-Rebases, dass alle anderen Entwickler ihren lokalen Zweig löschen müssen und eine neue Kopie von der Zentrale erhalten Repository (oder verwenden Sie einen anderen Zweig).Was passiert, wenn Sie Git Merge und Rebase kombinieren?

In dem Szenario, in dem mehrere Entwickler eine Zweigstelle teilen, ist git merge ein einfacherer Arbeitsablauf. Aber was ist mit der endgültigen Zusammenführung zu "Master", wenn das Feature abgeschlossen ist? Was passiert, wenn Sie "Rebase" auf dem Weg verwenden, um mit dem Master synchron zu bleiben? Sie haben "merge" verwendet, aber bei der letzten Lieferung an "Master" verwenden Sie eine interaktive "Rebase", um eine saubere, lineare Historie zu erhalten und uninteressante Commits quetschen? Was passiert insbesondere, wenn die Commits "merge" wiederholt werden oder wie behandelt git das?

Antwort

1

Rebase ist nur ein Problem, wenn Sie am Ende drücken drücken, aber jeder Vorgang ist ein Problem, wenn Sie das tun. In Ihrem Szenario, das mit einem Rebase in den Zielzweig endet, handhabt git das völlig in Ordnung und spielt die Zusammenführungen einfach mit möglichen Konflikten ab, wenn die gleiche Zusammenführung in Konflikt geraten wäre. In den meisten Fällen hat ein Rebase nur dann Probleme, wenn die entsprechende Zusammenführung auch Probleme gehabt hätte.

1

Normalerweise möchten Sie vermeiden, dass commits, die durch Push veröffentlicht wurden. In Ihrem Fall können Sie damit durchkommen, da Sie einen temporären Feature-Zweig rebasieren, und da Sie sehr klar mit Ihrem Team kommunizieren können (dh diejenigen, die in diesem Zweig arbeiten), dass der Zweig im Wesentlichen verschwindet, sobald die Entwicklung abgeschlossen ist wurden in deinen Master rebasiert.

Darüber hinaus gibt es nicht wirklich ein Problem mit der Neuausrichtung eines Zweigs, der Zusammenführungen enthält. Die Zusammenführungs-Commits vom Master werden einfach aus Ihrem rebasierten Zweig verschwinden (da diese jetzt rebasiert sind, sind diese Änderungen bereits integriert), und Sie können problemlos einen interaktiven Merge hinterher ausführen, um den Verlauf weiter zu bereinigen.

+0

Das Argument, das mir begegnet, ist, dass es schwierig sein würde, alle anderen Teammitglieder für die Rebase auszurichten. Ich bin mir nicht sicher, ob es wirklich ein Problem ist oder nicht. Sie müssten in der Lage sein, den entfernten Zweig zu verstehen und zu bewältigen, der plötzlich von ihrem lokalen abweicht. – Bryji

+1

Ja, Sie würden dies nur tun, wenn die Branche wirklich am Ende ihrer Lebensdauer steht (weil sie in den Master integriert oder auf diesen reformiert wurde). Im Idealfall würden Sie nach dem Rebase den Master-Zweig drücken und auch den entfernten Feature-Zweig löschen. Auf diese Weise sollte es für die anderen Mitglieder kein echtes Problem geben - abgesehen von allgemeiner Verwirrung natürlich, weshalb Sie diesen Workflow kommunizieren sollten. Abgesehen davon wird ihr lokaler (nicht reformierter und veralteter) Zweig nicht unterbrochen, sondern einfach obsolet. – poke

Verwandte Themen