git commit --magic
Trotz besten Vorsätzen kommt es doch hin und wieder vor, dass der Versionsbaum des aktuellen Software-Projektes eher nach einem von einer Katze bearbeiteten Wollknäuel aussieht, als nach Arbeit. Strategien zur Vermeidung gibt es genug, bei deren Interpretationen gibt es aber durchaus einen gewissen Spielraum. Wenn irgendwann keiner mehr weiß, was da im develop passiert, sollte man sich spätestens etwas überlegen. "Hauptsache der Master ist sauber" kann auch mal schiefgehen.
Alles sauber halten?
Grundsätzlich erstmal keine schlechte Idee. Vor jeder Aktion die gesamte lokale Historie squashen, einen Kommentar à la "ich hab da mal ein Feature geschrieben" hinterlassen und weg damit. Beim merge dann direkt ein rebase hinterherschieben und nochmal aufräumen. Was letztlich bleibt, ist im Rückblick ein neuer Stand, der wie durch Magie aus dem Nichts entstanden ist.
Der Verlauf ist wichtig, alles behalten?
Auch hier steckt Wahrheit drin. Ein Feature-Branch kann und sollte die Entstehung des Codes zeigen. Aber muss man deshalb jeden noch so überflüssigen Schritt, unvollständige Zwischenstände dokumentieren? Auch ist es nicht unbedingt sinnvoll, dem Rest der Welt (oder zumindest dem Teil mit Zugriff auf das Repository) jeden lokalen Testbranch zu präsentieren. Hin und wieder mag es interessant sein zu sehen, warum so und nicht anders geschrieben wurde, aber oft tut es da vielleicht auch ein simpler Kommentar.
Der goldene Mittelweg
Ja, die Wahrheit wird wohl irgendwo dazwischen liegen. Solange man alleine auf einem branch arbeitet sollte man hin und wieder Zwischenschritte squashen, bevor man seine Arbeit auf's origin pusht. Eine lineare Historie ist nicht immer spannend, Meilensteine, Subfeatures oder insbesondere auch bearbeitete Tickets sollten aber doch bitte stehen bleiben. Testbranches oder kleine Subfeatures muss man nicht unbedingt pushen, außer der Inhalt könnte die Kollegen wirklich interessieren.
Auch das mergen kreuz und quer zwischen den Branches kann häufig vermieden werden. Merged man Features bei repräsentablen (und funktionsfähigen) Zwischenständen zurück in den develop, muss der Kollege die Änderungen nicht unbedingt zwischendrin rausfischen, sondern hat eine klare Anlaufstelle. Möchte man seine Arbeit aus eventuellen Snapshot-Builds raushalten, kann man sie beim Einsatz von Buildtools immer noch hier ignorieren. Features, die über lange Zeit separat liegen, neigen leider auch dazu, merge-Konflikte anzusammeln.
Letztlich kommt es immer auf das Projekt und das Team an, mit welcher Schiene man am besten fährt. Soweit ich das ganze sehe, kann man sich allerdings viele Konflikte ersparen, wenn man vor jedem größeren Schritt - solange der Verlauf noch halbwegs linear ist - kurz innehält und noch einmal darüber nachdenkt, was man als nächstes tut. Ein Genie soll ja bekanntlich das Chaos beherrschen, aber was nützt es mir, wenn dieses Beherrschen mehr Zeit kostet als die eigentliche Arbeit... Umgekehrt bin ich auch ganz froh, wenn letztes auch ohne Magie auskommt.
Weiterlesen →