Git: Wie oft commitet ihr, wie oft pusht ihr remote?



  • Hi,

    ich habe einen GIT-Server und meinen Code auch lokal.

    Ich commite relativ selten, denke aber gerade daran das häufiger zu machen.

    Da stellt sich mir die Frage: Wie häufig commitet ihr und wie häufig würdet ihr dann zum GIT-Server pushen?

    Einige meinen, man solle nach jedem kleinen Feature direkten commiten. Aber wenn ich das mehrfach pro Stunde oder ein paar Stunden am Tag mache und dann jedes mal commite, verzögert mich das ja, wenn ich dann jedes mal auch pushe.

    Ach und wenn es dann ganz viele Mini-Commits gibt: Fasst ihr die in irgendeiner Weise zusammen? Ich hatte kurz überlegt, ob Branches da helfen, aber die sind dafür ja eigentlich nicht gedacht, würde ich denken.

    Mich würden da mal eure Vorgehensweisen interessieren.



  • Man muss doch nicht jeden commit direkt auch pushen. Ich committe immer wenn ich einen Teilaspekt fertiggestellt habe und pushe dann täglich. Manchmal räume ich das vorher dann auch noch auf wenn es Sinn macht.



  • Ich arbeite nach dem Schema: http://nvie.com/posts/a-successful-git-branching-model/

    Committen nach jeder Änderung, auch wenn sie noch so klein ist. Das macht es IMO einfacher Bugs, welche durch einen Commit geschaffen wurden, zu revidieren. So muss ich nicht dutzende Dateien untersuchen ob sie mit einer Änderung zusammenhängen oder nicht. Außerdem macht das die Commit-Message kürzer und simpler. So vergisst man auch nicht die kleinen Features in der Message aufzulisten, damit man später danach greppen kann.

    Zum zentralen Server wird am Ende des Arbeitstages gepusht, selten mehrfach pro Tag. Stelle dir einfach die Frage, warum du unbedingt pushen möchtest. Warten andere Leute auf deine Änderung? ⇒ pushen. Dringender Hotfix? ⇒ pushen.



  • Hi,

    super, der Artikel gefällt mir sehr gut. Alles brauche ich davon wahrscheinlich nicht, aber ein paar Branches anzulegen erscheint ja äußerst sinnvoll.

    Edit:
    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.

    Viele Grüße
    Eisflamme



  • Wenn man ohne starre Zuständigkeiten gemeinsam mit mehreren an einem Projekt arbeitet, ist häufiges pushen auch sinnvoll, um Doppelarbeit oder Konflikte möglichst zu vermeiden. Aber nur pushen, wenn etwas vollständig bzw. lauffähig ist, sonst stört man die Anderen.

    Mikrocommits hingegen finde ich persönlich ziemlich störend, weil sie nur das Log aufblähen. Nicht jede Korrektur eines Tippfehlers braucht einen eigenen Commit. Insbesondere stören solche Mini-Commits, wenn man später mal versuchen will, aus dem Git-Log aussagekräftige Releasenotes zu basteln.



  • 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-History

    Ich 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.


  • Mod

    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.


  • Mod

    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.


  • Mod

    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.


Anmelden zum Antworten