Git - wie man Änderungen richtig zurückstellt?

Question

Wir sind erst kürzlich zu git gewechselt (mit dem gitflow-Verzweigungsmodell) und haben einige Probleme, wenn wir Änderungen rückgängig machen müssen.

Leider entscheiden wir ziemlich oft, dass ein Feature in einem Release aufgrund von Problemen, die während der Regression oder zu irgendeinem Zeitpunkt des Testzyklus auftreten, nicht verfügbar sein wird. Wir können den Zusammenführungs-Commit für den Feature-Zweig einfach zurücksetzen, aber Feature-Verzweigungen, die nach dem Zusammenführen der fehlerhaften Änderung abgeschnitten wurden, enthalten diese Änderung und können sie zurück in die Entwicklung oder in einen Release-Zweig bringen, bevor sie freigegeben werden sollten.

Beispiel:

       |reverts f1 
develop-> X---o---o---Y---Z---R---P <- merge f2 to develop picks up f1 
      \  / \ /
     f1-> A---B---C f2-> D---E 

Aus dem Beispiel f1 geschnitten, bearbeitet, und fusionierte zurück zu entwickeln. f2 wird geschnitten und die Arbeit beginnt. f1 wird von develop at commit R zurückgesetzt. f2 wird dann vervollständigt und zurückgemischt, um bei commit P zu entwickeln. Commit P ist, wo das Problem ist: f1 kommt über dieses Commit zurück in die Entwicklung. Nun, gibt es etwas, was wir falsch machen mit den Rückgaben? Gibt es eine Möglichkeit, sicherzustellen, dass rückgängig gemachte Commits nicht zurück in die Entwicklung gelangen? Wir kehren mit 'revert -m1' zurück.

Gibt es irgendetwas, was wir falsch machen, wenn wir unsere Zusammenführungs-Commits rückgängig machen? Gibt es einen Weg, wie wir es so machen können, dass die Commits von f1, die f2 aufgenommen hat, nicht in die Zusammenführung mit einbezogen werden, um sie zu entwickeln? Müssen wir diese Commits für alle Forward-Feature-Zweige manuell zurücksetzen? Sollten wir stattdessen alle Feature-Zweige vom Master abschneiden, sodass wir wissen, dass sie keine Änderungen von Features übernehmen können, die zurückgesetzt werden könnten?

Alle Vorschläge sind willkommen, danke!

Answer 1

Ich glaube nicht, dass mit Ihrem Workflow etwas nicht in Ordnung ist, außer dass Sie das Zurücksetzen eines Commits berücksichtigen müssen, da es für alle untergeordneten Elemente gilt, nicht nur für den Entwicklungszweig. Weil der Feature-Zweig f2 auch die Änderungen für f1 hat, d. H. F2 = f2 + f1 in Ihrem Beispiel, und wenn Sie f2 wieder in git zusammenführen, denkt, dass Sie auch f1 zurück wollen.

In Ihrem obigen Beispiel könnten Sie ein Commit R 'auf dem f2-Zweig einfügen, um das zu erreichen, was Sie gerne hätten.

       |reverts f1 
develop-> X---o---o---Y---Z----R----P <- merge f2 to develop picks up f1 
      \  / \  /
     f1-> A---B---C f2-> D--R'--E 
           **|reverts f1** 

dies, dass f2 wird unter der Annahme, ist ein langer Laufzweig. Wenn das nicht der Fall ist und Sie erwarten, dass es sich um einen kurzen Zweig handelt, dann würde ich auf das Zurücksetzen R warten und es tun, nachdem Sie f2 und seine Schwestern wieder in die Entwicklung integriert haben. Dies kann nützlich sein, wenn Sie einige Features parallel bearbeiten.

         **|reverts f1** 
develop-> X---o---o---Y---Z-------P---R-- < 
      \  / \ /
     f1-> A---B---C f2-> D---E 

Hoffe, das hilft.