Was ist euch ein commit Wert?

[mutetella]

Hallo,

mich würde einfach mal interessieren, ab wann ihr ein neues changeset anlegt.

Es ist ja meistens nicht möglich, nur an einer Funktion oder Klasse oder wie auch immer zu arbeiten. Ich "entdecke" dabei oft noch kleinere Verbesserungen, die ich nebenbei noch erledige, mit der Hauptarbeit aber nicht unbedingt in Zusammenhang stehen.
Kommentiert ihr das alles mit? Oder beschränkt ihr euch lediglich auf größere Änderungen?

Gruß
mutetella

[Pekh]

Die Frage ist halt, inwieweit sich die Änderungen trennen lassen. Prinzipiell strebe ich aber schon an, für jede (noch so kleine) unabhängige Änderung ein eigenes Changeset zu erzeugen. Fällt mir "unterwegs" etwas auf, was auch noch geändert werden könnte / sollte, lege ich mir meistens ein Ticket (als Erinnerungsstütze) an und versuche, den Drang zur sofortigen Änderung zu unterdrücken, bis ich mit dem eigentlichen Problem fertig bin. Es gibt aber auch Fälle, wo diese Änderung die Ausführung der eigentlichen Arbeit beeinflußt. Dann entscheide ich mit Augenmaß, ob ich die Änderung "absorbiere" (also kein neues Changeset), oder ob es so grundlegend ist, daß ich zwei haben will. Ähnlich verfahre ich mit den entsprechenden Kommentaren. Prinzipiell sollte jede Änderung auch im Kommentar auftauchen, damit man es einfacher hat, sollte man zu einem bestimmten Programmstand zurückspringen wollen.

[.robert]

Bei mir wandelt sich das im Laufe der Entwicklung. Gerade am Anfang wenn das Programmgerüst und die grundlegende Struktur gebaut wird schreibe ich lieber Code als Commit-Messages. Später wenn es darum geht sich einzelnen Problemen oder Tickets zu widmen, achte ich schon darauf, lieber ein Changeset mehr als eins weniger an zu legen...

[DasIch]

Ein changeset sollte nicht mehr verändern als in einer Zeile (möglichst 50 Zeichen oder weniger) zusammenzufassen ist. Wenn ich dann doch mal "nebenbei" was finde nutze ich gits index, git add --interactive und stash um alles zu trennen.

[Leonidas]

Geht mir ganz ähnlich, ich nutze auch relativ gerne stash. Aber oft bin ich einfach recht faul und daher sind meine Commits wohl nicht so sehr sorgfältig, wie sie sein sollten.

[syntor]

Bei mir kommt das auch darauf an, was für ein System ich nutze. Ich arbeite gerne mit Git, da ist es nicht viel Aufwand, ständig was zu comitten, oder stashen. Wäre ich aber gezwungen SVN zu nutzen, wäre ich definitiv zu faul um so sorgfältig zu trennen.
Den Artikel von Pope, den DasIch verlinkt hat, finde ich sehr gut. Ein Gedanke hinter der 50-Zeichen Limite ist, dass Git an vielen Orten dir standardmässig nur ungefähr soviel anzeigt. Fasst du aber mehrere Änderungen in einem Commit zusammen, die du so nicht benennen kannst, hast du einfach keine Ahnung was in den Commits drinsteht wenn du z.B. git log verwendest, ausser natürlich du willst dich um die Formatierungseinstellungen bemühen.

[mutetella]

Ok, ich sehe schon, ich bin wohl etwas "commit-faul"... Ich arbeite mit Trac samt Mercurial-Erweiterung und schreibe beim Arbeiten parallel die Änderungen in ein Ticket, auf das ich dann im commit verweise. Und in so einem Ticket steht dann oft ein Haufen an Änderungen, bis ich endlich einen commit starte. Hat natürlich den Nachteil, dass das Repository sehr abhängig von Trac ist. Das werd' ich wohl ändern müssen...

git stash respektive hg shelve find' ich auch 'ne interessante Sache. Bisher halte ich es wie Pekh und lege mir beim Auftauchen eines "themenfremden" Problems ein Ticket an, damit ich so'n Zeug nicht vergesse...

Danke schon mal für Eure Beiträge...

Gruß
mutetella

[sma]

Ein Commit aka Submit aka Changeset sollte IMHO immer nur einen Aspekt ändern. Aufräumarbeiten "nebenbei" gehören in einzelne andere Commits. Bei Git gefällt mir, dass der Commit-Prozess zweistufig ist, d.h. ich kann zunächst auswählen, was ich "stagen" will, insbesondere betrifft dies auch Teile von Dateien. Und falls man sich vertan hat, kann man den letzten Commit sogar wiederholen. Dadurch kann man Ordnung halten und es seinen Mitentwicklern einfacher machen, zu verfolgen, was sich an der Software ändert.

Stefan

[snafu]

Ein Commit aka Submit aka Changeset sollte IMHO immer nur einen Aspekt ändern.

+1

Alles andere ergibt keine vernünftig nachvollziehbare Historie.

[mutetella]

Ok, ich geb' ja zu, die Frage ist jetzt vielleicht Korinthenkackerei:

Bevor ich beginne, an einer Klasse weiterzuarbeiten, fällt mir ein Instanzattribut auf, dem ich gern einen anderen Namen geben möchte. Würdet ihr das schnell "im Vorbeigehen" erledigen oder auch für solche Kleinigkeiten ein changeset anlegen?

[lunar]

Generell sind Änderungen an der Struktur des Quelltexts strikt zu trennen von funktionalen Änderungen. Das erleichtert die Fehlersuche, wenn man später merkt, dass man doch nicht ganz so sorgfältig war wie gedacht bei der Umbenennung dieses Attributs.

Grundsätzlich sind solche strukturellen Änderungen eigentlich auch nicht im "Vorbeigehen" getan, insbesondere nicht bei öffentlichen Attributen, die weiß Gott wo verwendet werden könnten. Dann müsste man im Idealfall erst einmal die natürlich möglichst vollständige Testsuite laufen lassen, um Regressionen zu verhindern, bevor man die Änderungen "committed" (gibt es dafür eine vernünftige deutsche Übersetzung?), und sich wieder funktionalen Änderungen zuwendet. Klar, die Realität sieht anders aus, aber versuchen kann man es ja wenigstens

[DasIch]

Bevor ich beginne, an einer Klasse weiterzuarbeiten, fällt mir ein Instanzattribut auf, dem ich gern einen anderen Namen geben möchte. Würdet ihr das schnell "im Vorbeigehen" erledigen oder auch für solche Kleinigkeiten ein changeset anlegen?

Ein Instanzattribut zu ändern ist keine Kleinigkeit von daher rechtfertigt dies durchaus einen changeset. Eine Ausnahme ist natürlich wenn es sich um ein Implementationsdetail handelt.

[lunar]

@DasIch: Selbst bei Implementierungsdetails oder privaten Attributen gehört das eigentlich in ein separates Changeset.