Git: Wie oft commitet ihr, wie oft pusht ihr remote?
-
Ich find daher die im Artikel erläuterte Struktur mit einzelnen Feature-Branches ganz sinnvoll. Das löst das Problem der Mini-Commits doch großteils, oder?
-
Für mich nicht. Unnützes branching find ich noch furchtbarer als Mikrocommits, weil das Branch-Chaos erfahrungsgemäß hinterher kein Mensch aufräumt. Außerdem finde ich arbeiten mit verschiedenen Branches sehr mühsam, also mach ich sowas nur für sehr große Umbauten, die ich nicht in zwei, drei Tagen wieder in funktionsfähigen Zustand kriege, und es mich daher bei anderen Entwicklungen aufhält (Für Kleinkram ist die Stash-Funktion von git ziemlich praktisch). Wenn man allerdings die Commits der Feature-Branch squasht, bevor man es nach master übernimmt, löst es zumindest das Mikrocommit-Problem.
Noch eine Anschlussfrage: Wie regelt ihr das mit verschiedenen Library-Versionen? Wenn ich für Release 2.0 einen Hotfix anbieten möchte, aber schon länger an Release 2.1 arbeite und für 2.1 auf eine neue Library-Version umgestiegen bin, muss ich beim Hotfix ja wieder mit der alten Library kompilieren.
Dann muss ich für alle Releases, die ich noch pflegen möchte, die Librarys aufbewahren, oder? Wenn es viele Versionen gibt, ist das ja echt lästig. Beispielsweise verbraucht QT viel Festplattenspeicher.
Ja, das dürfte unvermeidlich sein. Allerdings könnte man auch für alte Versionen die Abhängigkeiten bei Minor-Releases aktualisieren, sofern es keine Inkompatibilitäten gibt.
-
Was stört dich bei den Branches denn? Nach der Anleitung würde man eine Feature-Branch ja später einfach mergen und löschen. Du meinst, das passiert einfach nicht?
Klar, wenn sich die Leute nicht an die Regeln halten, ist das alles störend. Wenn man das weitestgehend ausschließen kann, stört dich dann noch etwas an den Branches?
-
Was stört dich bei den Branches denn? Nach der Anleitung würde man eine Feature-Branch ja später einfach mergen und löschen. Du meinst, das passiert einfach nicht?
Einerseits landen manche Features dann nie oder erst sehr spät im Master-Zweig. Solange wird kaum jemand Notiz davon nehmen und mitarbeiten, Fehler finden/beheben oder gar die Sache vervollständigen. Andererseits bleiben solche branches dann auch gerne mal überall vorhanden, selbst wenn sie gemergt wurden, sei es in lokalen Git-Repositories oder auch im remote-repository. Außerdem verlockt die Arbeitsweise dazu, viele Fässer aufzumachen, ohne ein einziges zu schließen. Dann hat man am Ende 20 offene Feature-Branches, nix davon ist fertig, nach 2 Monaten ists vergessen und man weiß auch nicht mehr, in welchem Zustand man die Sache hinterlassen hat. Das passiert insbesondere, wenn der Autor die Sache soweit lauffähig hat, dass es für seine eigenen Zwecke reicht, aber es so halbfertig ist, dass man sie nicht nach master mergen will. Und innerhalb der langen Liste von Branches findet man dann auch den Wald vor Bäumen nicht mehr. Außerdem hab ich dann auch immer Sorge, das ganze am Ende nur noch unter größter Mühe mit Änderungen in anderen branches zusammenführen zu können. Generell kann ich einer verzweigten Arbeitsweise wenig abgewinnen, ich gehe da lieber linear vor.
-
Eisflamme schrieb:
Ich find daher die im Artikel erläuterte Struktur mit einzelnen Feature-Branches ganz sinnvoll. Das löst das Problem der Mini-Commits doch großteils, oder?
Jein. Mini-Commits sind nicht unbedingt ein Problem. Feature-Branches sind eine gute Idee und viel übersichtlicher als wüstes Herumgestashe.
Wenn Mini-Commits zum Problem werden, kannst du sie vor dem Push squashen:
https://git-scm.com/book/en/v2/Git-Tools-Rewriting-HistoryIch squashe im Normalfall aber auch eher nur Mikro-Commits. Einigermaßen überschaubare Mengen von sinnvollen Mini-Commits sind durchaus ok.
Den git-flow-Workflow von nvie finde ich persönlich viel zu aufwändig und umständlich, aber er beschreibt genug Ideen, damit man sich auch etwas weniger umständliche Workflows überlegen kann. git-flow finde ich nur für sehr große Teams sinnvoll, die sehr viel Händchenhalten brauchen um keinen Blödsinn zu machen und/oder große Mengen von langlebigen Versionen auf längere Zeit warten müssen.
Mr X: Die von dir beschriebenen Probleme habe ich eigentlich nie. Klingt für mich alles so, als wären deine Feature-Branches zu langlebig. Ich habe kaum je mehr als drei oder vier Feature-Branches und merge die typischerweise innerhalb weniger Tage. Der Trick dabei ist der, "Features" viel kleiner anzusetzen als das, was Endusern oft als ein einzelnes neues Feature verkauft wird.
-
Mr X schrieb:
Insbesondere stören solche Mini-Commits, wenn man später mal versuchen will, aus dem Git-Log aussagekräftige Releasenotes zu basteln.
Selbst schuld wenn du sie daraus basteln willst. Die kommen aus JIRA oder einem anderen Issue-Tool. Commit early, commit often. Ich habe durchaus 10-50 Commits an einem Tag, da ändert sich dann meist auch nur noch eine Zeile oder eine Methode.
MfG SideWinder
-
Wir arbeiten zwar mit SVN, aber ich mache das wie SideWinder. Oft committen. Idealerweise so dass ich jeden Commit nochmal vollständig durchgucken kann und dabei jede Änderung und warum ich sie gemacht habe noch im Gedächtnis habe.
Wir haben ein anderes Team, die committen immer nur mehr oder weniger vollständige Features (=ganze JIRA Tickets). Und das erst nachdem die Änderung vollständig getestet wurde.
Also mehrere Tage coden (manchmal wochenlang!), dann nen kompletten Build machen, aufs Gerät spielen und dort testen. Nachbessern, nochmal Build, nochmal testen. Danach erst commit. Und wenn man Pecht hat davor nochmal ordentlich mergen.
Das wäre nix für mich.
Die Jungs dort sind allerdings auch der Meinung dass es gut funktioniert. Ich kann das zwar nicht nachvollziehen, aber ich schätze wenn man sich dran gewöhnt hat, wird man wohl auch damit klarkommen.Und was branches angeht: ich versuche so viel wie möglich im Trunk zu machen. OK, mit SVN Arbeiten ist hier wohl nicht ganz vergleichbar wie mit Git arbeiten, aber egal. Weil: je mehr Branches man hat, desto mehr (mMn. unnötiger) Aufwand wird verursacht wenn man z.B. Refactorings macht die viele Zeilen ändern (z.B. einfach ein paar Klassen umbenennen). Und desto eher macht man diese Refactorings dann eben nicht.
Ich vermute mal: Je sauberer ein Projekt aufgebaut ist, desto weniger ist das ein Problem. Meine grossen Projekte sind dummerweise relativ unsauber -- viel braunes Gras von Leuten übernommen die sich leider gar nicht drum geschert haben ob etwas wartbar ist oder nicht. Daher sind immer wieder Aufräumarbeiten nötig die z.T. sehr sehr viel Code betreffen. Wenn ich da immer mehrere Branches berücksichtigen müsste, dann könnte ich diese Änderungen einfach nicht machen.
Release-Branches sind natürlich ne andere Sache. Die sind toll - die bewirken nämlich genau das Gegenteil von Feature-Branches: sie ermöglichen es mir im Trunk gröber umzugraben ohne das aktuell anstehende Release zu gefährden.
-
Ja, den Commit zu reviewen halte ich inzwischen auch für sehr wichtig. Generell reviewen wir dann auch noch den Diff eines Feature-Branches bevor wir ihn mergen.
Lange feature-Branches sind aus Merge-Aufwands-Gründen bei uns auch nicht gerne gesehen.
Feature-Branches halte ich in der Multi-Team-Entwicklung für sehr wichtig um isoliert arbeiten zu können. Bei SVN auf Grund des zusätzlichen Aufwands vielleicht nicht machbar => einer wenn nicht der große Vorteile von Git ist imho das leightweight Branching-Modell.
MfG SideWinder
-
Ich committe nicht Micro-Änderungen, sondern Aufgaben-Basiert. Nicht ganze Features, aber Teil-Features. Meistens nach ein oder zwei Tagen. Schon alleine um Datenverlust zu vermeiden, damit die Arbeit nicht umsonst war.
-
Artchi schrieb:
Ich committe nicht Micro-Änderungen, sondern Aufgaben-Basiert. Nicht ganze Features, aber Teil-Features. Meistens nach ein oder zwei Tagen. Schon alleine um Datenverlust zu vermeiden, damit die Arbeit nicht umsonst war.
Also nach zwei Tagen wäre mir meist der Merge-Aufwand schon viel zu groß. Weiß nicht wie klein euer Team ist, aber bei 4-5 Developern wäre mir das zu anstrengend. Wir schauen, dass unsere Task-Größe 1 PT nach Möglichkeit nicht übersteigt. Größere Tasks haben meist eh viele Neuigkeiten und sind dementsprechend ohnehin besser isoliert.
MfG SideWinder
-
Wir sind zwar mehrere Personen, aber die meisten arbeiten an Einmann-Modulen. Und die, die zu zweit oder dritt arbeiten, committen entsprechend öfters aber sprechen sich ab, welche Dateien evtl. betroffen sind, da sie im selben Raum sitzen.
