Gibt es irgendwelche Fehler bei diesem Git-Verzweigungsmodell?

10

Ich frage nach diesem Git-Verzweigungsmodell oder Workflow. Ich mag das sehr. Es scheint mir sehr intuitiv und produktiv zu sein, aber ich frage, ob dieser Ansatz irgendwelche Mängel oder Nachteile aufweist, die mir noch nicht klar sind (aus einer anderen Welt, in der ClearCase den Tag regierte).

(Sie müssen nicht jede Frage beantworten, was auch immer Sie können, ist hilfreich)

Verwenden Sie diesen oder einen ähnlichen Git-Verzweigungs-Workflow?
Halten Sie dies für einen produktiven Ansatz?
Sehen Sie Fehler bei diesem Ansatz? Irgendwelche möglichen Nachteile?
Wenn Sie einen besseren Ansatz haben, würde es Ihnen etwas ausmachen, ihn zu teilen oder einen Link zu einem Artikel oder einer Diskussion darüber bereitzustellen?

git workflows

— Todd Hopkinson
quelle

6

Zum größten Teil ist dies der übliche Workflow, der bei allen bisher verwendeten VCS verwendet wird. Bei einigen (CVS, SVN) ist es schwieriger, bei GIT ist es trivial. Das heißt, ich habe zwei Bemerkungen:

Erstens gibt es zwei Denkschulen, wenn es um Feature-Zweige geht:

Füge sie zusammen
Rebase sie

(1) scheint der Artikel zu suggerieren. Das Problem bei Merge Commits sind sogenannte Evil Merges . Insbesondere diejenigen, die Entwicklungspfade verbinden, bei denen eine Funktion die Semantik in einem der Zweige geändert hat, die automatische Zusammenführung jedoch nicht alle Vorkommen im Code aus dem anderen Zweig korrigiert. Auf diese Weise eingeführte Regressionen sind bekanntermaßen schwer zu debuggen. Als GIT-Benutzer können Sie bei Regressionen in der Regel viel entspannter sein, da Sie git bisectderen Ursachen automatisch für Sie finden müssen. In der beschriebenen Situation git bisectwird jedoch auf das Zusammenführungs-Commit hingewiesen, was Ihnen überhaupt nicht hilft.

(2) vermeidet dieses Problem, indem versucht wird, eine möglichst lineare Historie aufrechtzuerhalten. Diese gegnerischen Rebases behaupten, dass alle Tests, die Sie möglicherweise vor dem Rebase durchgeführt haben, ungültig werden.

Persönlich bin ich fest im Lager (2), weil ich die Gültigkeit der git bisectErgebnisse mehr schätze als den potenziellen Verlust der Testabdeckung, der durch die Verwendung eines geeigneten CI-Systems leicht kompensiert werden kann.

Zweitens habe ich für mich entschieden, dass es selten eine gute Idee ist, zwischen Entwicklern zu wechseln. Es gibt Sicherheitsprobleme, die dazu führen, dass jeder in Ihre Box ssh kann, um Git-Deamon abzurufen oder lokal auszuführen, und, was noch wichtiger ist, in Teams, die nicht extrem klein sind, kann das Versehen ziemlich schnell verloren gehen.

Trotzdem bin ich für ein Staging-Repository (manchmal auch als Scratch bezeichnet ), mit dem die Unterteams ihre laufenden Arbeiten über einen zentralen Server teilen können, der sich jedoch vom Hauptserver unterscheidet (häufig nach außen). gegenüber, wenn nicht öffentlich). In der Regel verwaltet jedes Subteam einen Themenzweig für sich, und ein CI-System führt periodische Octopus-Zusammenführungen aller Themenzweige zu einem großen Integrationszweig durch, um sich über Konflikte und Erstellungsfehler zu beschweren.

— Gemeinschaft
quelle

+1, noch nie von einem Staging-Repository namens Scratch gehört, aber ich würde mir vorstellen, dass es von "von vorne anfangen" kommt :-)

— Spoike

@ ReinHenrichs: können Sie cool bleiben und darüber streiten, warum Sie mit Rebasing nicht einverstanden sind

— CharlesB

2

Es tut uns leid. Das behauptete Problem der Git-Halbierung existiert nicht. Git-Halbierung kann in Merge-Commits halbieren. Eine lineare Historie wird schwierig zu pflegen, wenn die Anzahl der Entwickler (oder aktuellen Zweige) zunimmt. Wenn Sie nicht verzweigen und zusammenführen, verlieren Sie außerdem ein sehr leistungsfähiges Workflow-Tool und einen der Hauptvorteile der Verwendung von Git. Sie müssen nicht "zwischen Entwicklern pushen", sondern können für jeden Entwickler ein entferntes öffentliches Repository (zumindest innerhalb des Entwicklerteams) einrichten. Das ist einfach. Was Sie im Wesentlichen beschreiben, ist die Verwendung von git wie svn.

— Rein Henrichs

"böse Verschmelzungen" werden durch Tests sauber verhindert . Die Merge-Commits selbst liefern nützliche Metadaten. Ich bin mir nicht sicher, welche Erfahrungen das OP mit der Pflege eines Git-Repositorys mit einer großen Anzahl aktueller Zweige hat. Wir haben die Strategie "Rebase and Flatten" mit einem Open-Source-Projekt mit Hunderten von aktuellen Zweigen ausprobiert und sie ist unter der Komplexität zusammengebrochen. Wir wechselten zu einer Zusammenführung Strategie und tat weg mit all der Komplexität während Dienstprogramm Zugabe ohne Leiden jeder der vermeintlichen Nachteile. git bisectwurde als Grund angegeben, die flache Strategie auch dann beizubehalten.

— Rein Henrichs

1

@ReinHenrichs Die von mmutz beschriebenen "bösen Verschmelzungen" haben nichts git bisectallein zu tun . Dies geschieht, wenn Merkmal A eine Funktion ändert, die auch Merkmal B verwendet. Alle Tests werden sowohl in A als auch in B vor dem Zusammenführen bestanden. Nach dem Zusammenführen können die Tests jedoch aufgrund inkompatibler Änderungen zwischen A und B unterbrochen werden. Sie git bisectkönnen jedoch einen Zweig nicht teilweise auf einen anderen anwenden. Daher ist der einzige Hinweis, dass das Zusammenführen festgeschrieben wird ist, als der Fehler eingeführt wurde.

— Izkata

2

Ich bin derzeit dabei, umfangreiche und langjährige Refactorings durchzuführen (Konvertieren einer Anwendung von einem in ein anderes GUI-Toolkit) und einen erfolgreichen, auf die Basis ausgerichteten Workflow durchzuführen, da andere Teammitglieder weiterhin an neuen Funktionen arbeiten:

Es gibt hauptsächlich zwei Hauptzweige, den Bereich, masterin dem die neuen Funktionen entwickelt werden, und den toolkit-conversionZweig. Die wichtigste Regel ist einfach: Machen Sie nur Dinge in der toolkit-conversionBranche, die für die Konvertierung relevant sind. Immer wenn im master(alten GUI-Toolkit) etwas getan werden kann , mache ich es dort und stelle meine toolkit-conversionÄnderungen auf den neuen masterKopf. Eine andere Regel ist, den toolkit-conversionZweig ziemlich kurz zu halten . Daher verwende ich oft Reset, Cherry-Pick und Amendment-Commit und Rebase, um kleinere Commits auf größere zu kleben (die am Ende den gleichen Zweck haben). Dies funktioniert auch gut, wenn ich etwas ausprobiert habe, das nicht gut funktioniert hat, um die Änderung rückgängig zu machen, oder nachdem ich einen Code mit temporärem Hilfecode überarbeitet habe.

Ich habe gegen Änderungen aus der Verschmelzung beschlossen masterin toolkit-conversionZweig, weil sie es viel schwieriger machen würden früher Commits rebase den Zweig sauber und einfach zu Auge zu behalten. Außerdem können Zusammenführungen zu Konflikten führen, deren Lösungen nicht so klar sind wie bei einer sauberen Historie.

Natürlich hat dieser Workflow auch Nachteile. Das wichtigste ist, dass es nur für eine einzelne Person gut funktioniert. Immer wenn ich den toolkit-conversionZweig nach dem erneuten Basieren auf den Kopf von masterzwinge, wird es schwierig, ihn in ein anderes Repository zu ziehen (das automatische erneute Basieren auf den Verfolgungszweig schlägt häufig mit Konflikten fehl).

Am Ende toolkit-conversionbleibt meine Filiale kurz, sauber und leicht zu überprüfen. Ich konnte mir nicht vorstellen, dies ähnlich mächtig mit z. B. SVN zu tun.

2

In der Firma, in der ich gerade arbeite, wenden wir seit einiger Zeit eine Variation desselben Verzweigungsmodells an. Wir haben auch Scrum verwendet, um einen Zweig pro Story-Workflow zu erstellen.

Das einzige Problem, das wir bisher hatten, ist, wenn das Team groß genug ist und mehr als eine Geschichte gestartet werden kann und diese Geschichten voneinander abhängig sind, wird es zu einer Art Chaos, Änderungen zwischen Zweigen und zurück zum Meister zusammenzuführen.

Außerdem hat sich dies als vertrauenswürdig erwiesen :).

— Edgar Gonzalez
quelle

1

Ich bin gerade damit beschäftigt, diesen Workflow anzupassen. Ich denke, dies ist ein ziemlich guter Workflow, da er das Verzweigungsmodell verwendet, in dem sich Git auszeichnet.

Der einzige kleine Nachteil ist, dass es etwas Disziplin erfordert, diesen Workflow beizubehalten und nicht zu versuchen, Verknüpfungen zu verwenden.

Die Entwickler von kohana verwenden diesen Workflow ebenfalls und sie scheinen ihn sehr zu mögen.

— Ikke
quelle

1

Verwenden Sie diesen oder einen ähnlichen Git-Verzweigungs-Workflow?

Wir verwenden einen ähnlichen Workflow bei der Arbeit, der jedoch etwas weniger kompliziert ist. Es ist jedoch stark von diesem Workflow inspiriert, da ich diesen Artikel oft gelesen habe. Ich habe sogar das PDF des Verzweigungsmodells in Farben neben meinem Schreibtisch gedruckt :)

Halten Sie dies für einen produktiven Ansatz?

Produktiv. Wie definieren Sie Produktivität? Meiner Meinung nach ist es am wichtigsten, eine hohe Qualität zu haben, zumindest um immer eine bessere Qualität zu erreichen. Ständige Verbesserung des Prozesses usw. Wenn Sie Qualitätscode erstellen können, wird die Produktivität davon profitieren. Die Frage ist also wirklich: Verbessert dies die Qualität der Software? Und meine Antwort darauf lautet definitiv ja.

Was ich an dieser Art von Verzweigungsmodell am meisten liebe, ist, dass es Verzweigungen in verschiedenen Qualitätsschichten einführt. Je weiter rechts im Bild, desto höher die Stabilität und desto höher die Qualität. Der Master-Zweig ist heilig und alle Commits sollten als stabile Versionen der Software angesehen werden. Je weiter Sie nach links gehen, desto experimenteller und desto geringer ist die Stabilität.

Sobald Sie neue Funktionen und Fehlerbehebungen testen, können Sie diese schrittweise von links nach rechts übertragen und so Code mit hoher Qualität einfügen, genau dann, wenn Sie wissen, dass der Code die Qualitätsanforderungen erfüllt, die Sie an den Code stellen. Zumindest theoretisch, da Sie nicht alles zu 100% testen können und sicher wissen, dass der Code keine Fehler enthält, da er immer Fehler enthält. Aber es ermöglicht Ihnen, ein hohes Vertrauen zu behalten.

Nichts ist für einen Programmierer schlimmer, als in einem System zu arbeiten, in dem niemand Vertrauen in den Code hat, weil er weiß, dass er nur scheiße ist und dass es eine Menge Fehler darin gibt.

Sehen Sie Fehler bei diesem Ansatz? Irgendwelche möglichen Nachteile?

Es ist wichtig, dass Sie Ihr Verzweigungsmodell durchdenken, damit es gut zu den Anforderungen Ihres Unternehmens passt. Nur weil dieses Modell für manche Menschen gut funktioniert, heißt das nicht unbedingt, dass es für andere optimal oder wünschenswert ist.

Es gibt immer Kompromisse und auch in diesem Fall. Ein Kompromiss ist die Anzahl der Filialen gegenüber der Komplexität. Durch die Einführung vieler verschiedener Zweigstellentypen erhöhen Sie die Komplexität des Workflows. Zum Beispiel kann es einfach falsch sein, Leute immer zu zwingen, einen neuen Feature-Zweig zu erstellen, wenn sie versuchen, einen einfachen Fehler durch Ändern einiger Codezeilen zu beheben.

Wir alle wissen, dass Fehler mehr oder weniger kompliziert zu lösen sind. Wenn also ein trivialer Fehler entdeckt wird, möchten Sie möglicherweise die Komplexität und Verwaltung reduzieren, um zusätzlichen Aufwand zu vermeiden und die Leute direkt an den Master oder den Entwicklungszweig zu binden. Da die Art Ihrer Korrekturen jedoch komplizierter wird, lohnt sich der zusätzliche Aufwand, um neue Zweige für sie zu erstellen. Vor allem, wenn Sie sich über Größe und Länge nicht sicher sind oder wenn Sie die Zusammenarbeit zwischen Ihnen und den anderen Entwicklern verbessern möchten.

Wenn Sie einen besseren Ansatz haben, würde es Ihnen etwas ausmachen, ihn zu teilen oder einen Link zu einem Artikel oder einer Diskussion darüber bereitzustellen?

Dies ist zweifellos ein guter Ansatz und passt möglicherweise in die meisten Fälle, da die meisten von uns ähnliche Entwicklungsprozesse haben, aber möglicherweise nicht für jeden geeignet. Ich fordere Sie dringend auf, darüber nachzudenken, wie Sie jetzt mit Ihrem Code umgehen, und zu versuchen, ein Verzweigungsmodell zu erstellen, das zu dem passt, das Sie bereits haben.

Der wichtigste Punkt ist, mit Git zu beginnen und der Rest wird natürlich folgen. Fangen Sie einfach an und verbessern Sie sich allmählich! Seien Sie kreativ!

Prost