Welches SCM benutzt ihr?
-
Mich wuerd mal interessieren wie granular eure git commits sind? commitet ihr nur fertige Features oder auch Zwischenschritte? Halbfertige Zwischenschritte?
Und falls ihr mehr als nur komplette Features commited: gehen die nur in die branch, in die ihr grad arbeitet (bzw. ins lokale Repo), und werden danach zu einem einzelnen kommit fuer den localen master (globalen Master) gesquashed?
Wie handhabt ihr sowas?
-
Ich hatte es glaub ich schon geschrieben.
Ich entwickel in einem dev Branch, und submitte immer wenn ich den PC aus mache, egal ob es fertig ist oder nicht, auch egal ob es überhaupt baut.
Immer wenn dann ein Feature fertig ist, Merge ich es nach main und label dort zusätzlich.
So habe ich in main die letzte Stable und in dev das aktuellste.
-
Blue-Tiger schrieb:
Mich wuerd mal interessieren wie granular eure git commits sind?
So klein wie möglich. Allerdings nur so granular, dass ich nicht ständig git add -p oder -i verwenden muss. Gesquasht wird nicht, oder nur extrem selten.
-
Blue-Tiger schrieb:
Mich wuerd mal interessieren wie granular eure git commits sind?
Ich habe ebenso einen Dev. branch,
deventund commite nach jedem fertigen Zwischenschritt. Wenn ich fertig bin, merge ich alles inmasterund pushe es zum Server.
-
DEvent schrieb:
Blue-Tiger schrieb:
Mich wuerd mal interessieren wie granular eure git commits sind?
Ich habe ebenso einen Dev. branch,
deventund commite nach jedem fertigen Zwischenschritt. Wenn ich fertig bin, merge ich alles inmasterund pushe es zum Server.Und was, wenn du mehrere Feature-Branches hast? Gibts dann eine devent.<FEATURE> Branch für jedes Feature?
-
Mr. N schrieb:
DEvent schrieb:
Blue-Tiger schrieb:
Mich wuerd mal interessieren wie granular eure git commits sind?
Ich habe ebenso einen Dev. branch,
deventund commite nach jedem fertigen Zwischenschritt. Wenn ich fertig bin, merge ich alles inmasterund pushe es zum Server.Und was, wenn du mehrere Feature-Branches hast? Gibts dann eine devent.<FEATURE> Branch für jedes Feature?
Oder einfach
<FEATURE>. Man braucht kein Namespace für Git.deventist halt mein Dev.-Branch.
-
DEvent schrieb:
Oder einfach
<FEATURE>. Man braucht kein Namespace für Git.deventist halt mein Dev.-Branch.Ja, aber benutzt du die devent-Branch auch für Entwicklung in Feature-Branches? Das wird ja eigentlich wohl kaum gehen... Also musst du entweder direkt in der Feature-Branch entwickeln, oder eine eigene Dev-Branch für die Feature-Branch einrichten.
Aber ehrlich gesagt halte ich ohnehin nichts von Dev-Branches. Ich habe hier eine master-Branch und viele Feature-Branches. Und für alte Release-Serien eben Release-Branches bei Bedarf (also wenn z.B. 0.10 aktuell ist, gibt es eine release-0.9 Branch für die Entwicklung der 0.9.x Serie).
-
Mr. N schrieb:
Blue-Tiger schrieb:
Mich wuerd mal interessieren wie granular eure git commits sind?
So klein wie möglich. Allerdings nur so granular, dass ich nicht ständig git add -p oder -i verwenden muss. Gesquasht wird nicht, oder nur extrem selten.
aber hast dann nicht ein furchtbar unuebersichtliches log/history?
BTW: loescht du feature-branches, wenn sie fertig implementiert sind, oder behaelst du sie bei (oder verwendest sie gar weiter)?
-
Blue-Tiger schrieb:
Mr. N schrieb:
Blue-Tiger schrieb:
Mich wuerd mal interessieren wie granular eure git commits sind?
So klein wie möglich. Allerdings nur so granular, dass ich nicht ständig git add -p oder -i verwenden muss. Gesquasht wird nicht, oder nur extrem selten.
aber hast dann nicht ein furchtbar unuebersichtliches log/history?
Ein Log sollte doch dokumentieren welche Änderung wieso gemacht wurde. Da sind viele kleinere commits doch besser als ein großer commit?
-
DEvent schrieb:
Ein Log sollte doch dokumentieren welche Änderung wieso gemacht wurde. Da sind viele kleinere commits doch besser als ein großer commit?
Na ja, kommt drauf an. Ich denk mir halt, ein commit das 7 Dateien umfasst und dessen commit-messageueberschrift "implemented document saving functionality" uebersichtlicher als 6 Commits mit "Added SaveCommand class." "connected SaveCommand with GUI." "fixed Bug in SaveCommand & iostreams." "redesigned SaveCommand to work with different iostreams." "Changed gui icon for saving." "fixed GUI bug".
Alternativ koennt man ja einen "savecmd"-branch machen, da wirklich "detailiert" committen, aber dann halt beim merge squashen. Zerstoert zwar die Tree-Struktur, dafuer bleibt das log vom head schoen uebersichtlich.
Aber ich hab kaum Erfahrung mit git, deswegen wollt ich mal nachfragen wie andere das handhaben und ein Gespuehr von den "git best practices" zu kriegen.
-
Blue-Tiger schrieb:
aber hast dann nicht ein furchtbar unuebersichtliches log/history?
BTW: loescht du feature-branches, wenn sie fertig implementiert sind, oder behaelst du sie bei (oder verwendest sie gar weiter)?
Das Log ersetzt keine ChangeLog.txt, von daher sehe ich da kein Problem. Kleine Commits haben eben viele andere Vorteile, gerade für Dinge wie Cherry Picks und Fehlersuche.
Ja, ich lösche Feature-Branches, wenn sie in master sind, meistens.
-
Blue-Tiger schrieb:
DEvent schrieb:
Ein Log sollte doch dokumentieren welche Änderung wieso gemacht wurde. Da sind viele kleinere commits doch besser als ein großer commit?
Na ja, kommt drauf an. Ich denk mir halt, ein commit das 7 Dateien umfasst und dessen commit-messageueberschrift "implemented document saving functionality" uebersichtlicher als 6 Commits mit "Added SaveCommand class." "connected SaveCommand with GUI." "fixed Bug in SaveCommand & iostreams." "redesigned SaveCommand to work with different iostreams." "Changed gui icon for saving." "fixed GUI bug".
Alternativ koennt man ja einen "savecmd"-branch machen, da wirklich "detailiert" committen, aber dann halt beim merge squashen. Zerstoert zwar die Tree-Struktur, dafuer bleibt das log vom head schoen uebersichtlich.
Aber ich hab kaum Erfahrung mit git, deswegen wollt ich mal nachfragen wie andere das handhaben und ein Gespuehr von den "git best practices" zu kriegen.In Git ist die erste Zeile einer Log-Message die Kurzzusammenfassung/Thema. Wenn du z.B. auf http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary gehst, siehst du das "Shortlog", das Zeigt dir diese erste Zeile an. Somit kannst du immer die Commits nach einem Thema einordnen.
Mehr Details dafür gibts auf A Note About Git Commit Messages
-
Blue-Tiger schrieb:
Alternativ koennt man ja einen "savecmd"-branch machen, da wirklich "detailiert" committen, aber dann halt beim merge squashen. Zerstoert zwar die Tree-Struktur, dafuer bleibt das log vom head schoen uebersichtlich.
Aber ich hab kaum Erfahrung mit git, deswegen wollt ich mal nachfragen wie andere das handhaben und ein Gespuehr von den "git best practices" zu kriegen.Das mache ich häufig, wenn ich wiedermal eine schnell zusammengeworfene Implementierung gebastelt habe und die dann so refaktorisiere, dass am Ende was halbwegs hübsches und elegantes rauskommt.
Also eben statt vier Commits mit insgesamt +100 Zeilen und -70 Zeilen zusammensquashen und rebasen zu einem einzigen mit 30 Zeilen. Hängt aber stark davon ab, was ich gerade mache, wie ekelhaft die Zwischenschritte waren, wie nachvollziehbar meine Änderungen mit bzw. ohne Squash sind etc.
Ansonsten wohl ziemlich ähnlich wie MrN: Sobald ich was kleines habe, was in sich einigermaßen abgeschlossen ist und ein sinnvolles Changeset ergibt, committe ich. Wenn ich Bugs finde, wechsle ich zum Master-Branch zurück, fixe und committe dort. Git stash kommt bei mir auch häufig zur Anwendung, insbesondere wenn ich wiedermal mit irgendwas neuem begonnen habe, das eigentlich in eine neue Branch sollte, dann stashe ich direkt in frische Branches weg.
Ich mache häufig frische Feature-Branches auf, rebase die dann zum Master und lösche sie. Manche Projekte bevorzugen Merges statt Rebases, daran halte ich mich natürlich dann auch.