Wie oft und wann vor allem commiten in Git

[PEASANT KING]

Guten Morgen,

ich arbeite schon einige Zeit mit Git für meine Projekte. Zuvor hatte ich SVN benutzt wie bestimmt viele hier in unserem Kreise.
Als ich das erste Mal Git wirklich versucht habe zu verstehen, habe ich gemerkt wie simpel und mächtig Git ist.

Allerdings stelle ich mir immer wieder die Frage, wie ihr Anderen mit Git arbeitet.
Z.B. stelle ich mir die Frage, wie oft man comitten sollte, also sobald ich an nur einer Datei eine Änderung gemacht habe im Quellcode der minimale Auswirkungen hat. Vielleicht ist diese Frage auch einfach dumm, aber ich habe oft das Problem das ich an vielen Stellen im Code was änder es dann committe, der Kommentar allerdings nicht zu jeder Änderung im Quellcode passt.

Andere Frage wäre auch wenn sollte man committen, ich weiß man sollte sehr viel committen damit wenn mal was schief geht man auch einfach zurück zum vorherigen commit wechseln kann. Wie macht ihr das so?

Andere Sache branching betreiben, ich habe mir vor genommen, sobald ich ein neues Feature programmiere einen Branch an zu legen und wenn das Feature funktioniert, das Ganze mit dem Master zu mergen. Oft erwische ich mich aber auch an anderer Stelle noch was zu verbessern was mit dem eigentlichen neuen Modul nur bedingt zu tun hätte.

Wie macht ihr es hier in diesen Fällen.

Vielen Dank für eure Antworten und Tipps. schon mal.

 

[honky-tonk]

bei bugfixes o.ä. kann ein commit auch mal nur ein zeichen beinhalten. Ansonsten wenn du ein feature entwickelst committe ich wenn das feature fertig ist. wenn es ein sehr großes feature ist würde ich es in verschiedene teilprojekte /tasks unterteilen die jeweils committed werden wenn sie fertig sind. pro commit dann immer nur ein feature/subfeature egal wieviele dateien die änderung betrifft. Diese gruppierung hilft dir nachzuvollziehen welche änderungen nötig waren für dieses feature. bzw wenn du das feature rückgängig machen möchtest musst du einfach nur den commit zurücksetzen.

 

[theEvil007]

Die Herausforderung stellt sich nahezu jedem, der entwickelt. Du musst Dich dabei selbst Disziplinieren. Wir halten uns an Grundsätze wie z.B. nur getestete Änderungen werden committed, jede Änderung ist ein Commit mit entsprechendem Kommentar. Das ist wichtig, insbesondere wenn es Teamarbeit ist.
Features werden in separaten Branches entwickelt, getestet und bei Bedarf in den Master gemerged.

 

[SaxnPaule]

Der Master enthält immer den Stand des letzten releasten Tags.
Entwickelt wird auf dem develop branch. Wenn es ein etwas größeres Feature ist, dann wird vom develop ein Feature branch erstellt und nach Fertigstellung zurückgemerged.
Aus dem develop wird bei Release ein Tag erstellt und dieser auch auf den Master gemerged.

Eingecheckt (gepusht) wird nur lauffähiger Code, es sei denn ich befinde mich in meinem eigenen Feature branch.

So handhaben ich das.

 

[PEASANT KING]

Danke schon mal für eure Infos soweit, aber wie schaut es aus mit den Comments in den jeweiligen Commits.
Committet ihr jede Änderung und dann mit einem eigenen Kommentar? Weil wenn das so wäre müsste ich jede Datei die ich angefasst habe auch wenn du die Eine seperat committen mit einem Kommentar.

 

[new Account()]

Wie oft commiten?
Sehr oft: jede logische Änderung = 1 commit. Damit sind die commits nicht groß. Warum? so profitiert man wirklich Von commits, da man später sehr leicht beliebig Änderungen rückgängig Machen Kann, ohne Chaos zu kreieren. Statt "remove blabla again" heißt es dann "revert commit xxxx".
Zum Bennenen: Überlege (Mach das bitte wirklich): Angenommen ich commite jetzt mit dieser Nachricht und ich möchte die Änderung später rückgängig Machen, Wird es Mir möglich sein diese commit danach schnell wieder zu finden? (Via Suchfunktion)

Ergänzung (28. Dezember 2018)

Wenn die zwei Dateien zu einer logischen Änderung gehören: pack die in einen commit.

Z.b.
"rename blo to bla"

Was auch manchmal hilfreich ist, ist die erweitere Commitnachrichtansicht: wenn du z.b. GitHub, gitlab, Oder einige git clients benutzt, wird die commit Nachricht in zwei Sektionen unterteilt.
Um den Effekt ohne git client Unterstützung zu bekommen, macht man einfach zwei Mal Neue Zeile. Das wird häufig genutzt um weitere Detailinformationen zum commit zu nennen:

"Rename blo to bla

According to issue #6"

"Rename blo to bla

Required by rule xxx of xyxyxy"


Edit: korrektes bezeichnen Von commits muss man üben, du wirst es selbst merken, wenn du einen commit suchst, den Aber nicht Mehr findest.

 

[theEvil007]

Wenn Deine Anpassungen in Dateien logisch zusammengehören, dann gehören diese auch in einen Commit mit dem entsprechenden Kommentar. Wenn sie nicht zusammengehören, dann alle einzeln und demzufolge auch einzeln kommentiert. Das ist zwar ein Aufwand, allerdings gewöhnt man sich schnell daran und empfindet es alsbald nicht mehr als Aufwand, sondern als konsequente Umsetzung.

 

[PEASANT KING]

Okay vielen Dank, dann werde ich in Zukunft noch häufiger commiten.

Außerdem werde ich dann für jede neue Funktionalität einen Branch eröffnen, der wenn die Funktionalität steht und funktioniert in den Master gemerged wird, bzw. in einen Release banch.

 

[voodoo44]

Ich weiß nicht, ob jemand das hier schon erwähnt hat: Bitte den Unterschied zwischen Commit und Push beachten .... :-)