Fehlerkorrekturen in einem Feature-Zweig
Wir verwenden ein erfolgreiches Git-Verzweigungsmodell von Vincent Driessen für unsere Verzweigung Modell. Alles in Ordnung, aber ich habe nicht wirklich ein bestimmtes Problem angesprochen.
Soweit ich es verstanden habe, wenn eine neue Funktion benötigt wird, verzweigen Sie den development und erstellen einen neuen feature Zweig. Sie würden daran arbeiten, und wenn Sie fertig sind, würden Sie diesen Zweig in den Zweig development zusammenführen.
Was passiert, wenn ein Entwickler ein Feature erstellt und dieses Feature dann wieder mit development zusammenführt, um herauszufinden, dass der Feature-Code einige Fehler enthält? Wo sollte das repariert werden? Soll ein neuer fix / bugfix Zweig von der Entwicklung gestartet und der Code dort festgelegt werden? Ich kann keinen anderen Weg sehen.
Wie soll man das machen?
Danke
4 Antworten
Denken Sie daran, dass ein Modell nur ein Modell ist - es geht darum, Ihnen eine Struktur zu geben, die Sie effizienter macht, nicht blind einer Reihe von Regeln zu folgen. Das bedeutet, dass Sie sich frei fühlen sollten, Dinge zu optimieren und herauszufinden, was in Ihrer Situation funktioniert, weil es möglicherweise nicht in jeder Situation funktioniert.
Ich denke, Sie haben eine Wahl in dieser Situation:
- Rollt die Zusammenführung zurück und setzt die Arbeit am Feature-Zweig fort, bis sie fertig ist
- Starten Sie einen neuen Zweig, um den Fehler zu beheben.
Welche Sie wählen, hängt von Faktoren ab wie:
- Können Ihre Kunden den Fehler sehen? Machen Sie einen Bugfix oder Hotfix-Zweig.
- Ist der Fehler wirklich schlimm und stoppt andere Fortschritte im Entwicklungszweig? Roll die Änderung zurück.
- Ist es nur ein geringes Problem mit minimalen externen Auswirkungen? Fahren Sie einfach mit der Arbeit am Feature-Zweig fort und fusionieren Sie erneut, wenn Sie fertig sind.
Der Unterschied zwischen einem Feature-Zweig und einem Bugfix-Zweig ist aus der Sicht von Git nicht wichtig. Es spielt nur eine Rolle, ob Sie diese Labels für die interne Dokumentation oder andere Überwachungszwecke verwenden (z. B. um zu verfolgen, was für externe Benutzer sichtbar ist).
Widerstehen Sie der Versuchung, direkt vom Entwicklungszweig zu arbeiten, auch wenn Sie denken, dass der Bugfix sehr schnell sein wird - nichts ist so einfach wie es scheint, und Sie werden sich später Kopfschmerzen zufügen, wenn etwas schief geht.
>Grobe visuelle Darstellung Ihrer Auswahl:
Wie wäre es mit das Commit zu finden, das den Bug einführte, und einen neuen Zweig gründen, der dort verwurzelt ist ? Mit diesem Ansatz:
- Es besteht kein Risiko, dass aufgrund von Rebase-Vorgängen fehlerhafte Referenzen erstellt werden
- Nur aus der Herkunft des Entwicklungszweiges, des Feature-Zweigs und anderer betroffener Zweige können Sie erkennen, wo Sie Ihren Bugfix-Zweig einfügen sollen, sobald er fertig ist. Dies gilt auch, wenn "Feature" seit der Einführung des Fehlers mehrmals mit "Entwicklung" zusammengeführt wurde.
- Wenn Sie den Commit, der den Fehler eingeführt hat, und root von dort identifizieren, können die Entwickler feststellen, wo sie den Bugfix-Zweig zusammenführen müssen, auch wenn sie das Repo-Layout nicht kennen
- Sie haben einen Zweig, den Sie zusammenführen können, ohne befürchten zu müssen, dass nachfolgende Änderungen in Zusammenhang stehen. Nehmen wir zum Beispiel an, dass jemand an "Feature-Beta" arbeitet, einem Unterzweig von "Feature", der kurz nach der Einführung des Fehlers divergierte. Sie können den Fehlerbehebungszweig leicht erfassen, ohne sich darum kümmern zu müssen, alles andere, was in "Feature" aufgetreten ist, einzuziehen.
- Diese Herangehensweise verringert den Bedarf an "cherry-pick", was den Nachteil hat, dass der Name von commits geändert wird (was einen der großen Vorteile von git untergräbt, nämlich einen eindeutigen Namen auf alles anzuwenden.)
Wenn es sich bei diesem Feature-Zweig um einen öffentlichen Zweig handelt (d. h. an einen Remote-Repo, der geklont / von anderen verwendet wird), ist es am besten, einen neuen Zweig zu erstellen und das Debug in diesem Fix-Zweig zu isolieren
(Anstatt zu versuchen, den Zweig ' feature ' auf den Zweig ' develop ' neu zu setzen).
Die Idee bleibt, Zwischen-Debug-Commits nicht direkt in develop branch aufzunehmen, sondern nur den resultierenden Commit aufzuzeichnen, der den von feature branch merge angestoßenen Fehler an erster Stelle beheben wird.
Machen Sie einfach eine Verzweigung (oder verwenden Sie den alten, zusammengeführten Zweig feature ) und reparieren Sie ihn dort.
Die alte Verzweigung / neue Verzweigung verwenden ist genau das gleiche - Sie können nicht angeben, welche Datei nach dem Zusammenführen angezeigt wird.
Tags und Links git git-branch branching-and-merging feature-branch