Ich bin der festen Überzeugung, dass es eine gute Praxis ist, sich zu einem Thema zu verpflichten. Ich bin sicher, ich habe es irgendwo in einem Artikel wie "Best Practices" gelesen.

Daher war mein Workflow wie folgt:

Für eine neue Ausgabe erstelle ich eine neue lokale Filiale mitgit checkout -b new-issue.Übernehmen Sie alle Änderungen. Manchmal geht es darumviele von Commits.Wenn ich fertig binsquash die Commits undrebase sie in aktuellen thematischen Zweig.Wenn etwas schief geht, kann ichgit revert Suchen Sie den Fehler, beheben Sie ihn und übertragen Sie neuen Patch in den thematischen Zweig. Ich werde den Verlauf des Remote-Repositorys nicht ändern.

Aber heute war ich überrascht, den folgenden Workflow zu hören:

Erstellen Sie eine neue Filiale für die neue Ausgabe.Setze alles ein.Benutzenmerge --no-ff um den Issue-Zweig mit dem thematischen Zweig zusammenzuführen (so dass wir "Merge-Commit" haben, das wir können)revert).Wenn etwas schief geht, können wir verwendengit bisect um den Bug zu finden.

Nach dem ersten Ansatz haben wir eine saubere Git-Historie und keine Ahnung, welche Overhead-Zweige während der Entwicklung verwendet werden.

Nach dem zweiten Ansatz haben wir einen sehr chaotischen Verlauf mit vielen hässlichen, unnötigen Zusammenführungen und Commits für nur ein Problem. Wir können jedoch verwendengit bisect Fehler zu finden. (Vielleicht ist dies besser für das Refactoring?)

Welche Vor- und Nachteile sehen Sie für beide Ansätze?

Welchen Ansatz verwenden Sie und warum?

In der Praxis hast du das eigentlich benutztgit bisect Fehler zu finden? (Ich habe nicht ...)