Arbeiten mit Git / Zeitpunkt für Commits?

  • Allgemein

Es gibt 9 Antworten in diesem Thema. Der letzte Beitrag () ist von EaranMaleasi.

    Arbeiten mit Git / Zeitpunkt für Commits?

    Servus Leute,

    wie viele von euch benutze ich auch Git \ SVN \ usw.
    Nach einigem Arbeiten fällt mir immer wieder auf, dass sich bei mir teils Änderungen an 20+ Dateien ergeben, ohne dazwischen einen Commit zu machen. Das Problem ist jedoch, dass oftmals alle diese Änderungen irgendwie aufeinander aufbauen und verteilt auf mehrere commits kein auch nur annähernd lauffähiger Zustand entsteht, außer natürlich beim letzten Commit. Um dennoch das ganze auf mehrere commits aufzuteilen fasse ich dann die Änderungen thematisch zusammen, was jedoch auch irgendwie falsch erscheint.

    Wie ist hier die "richtige" Vorgehensweise?

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „EaranMaleasi“ ()

    @EaranMaleasi Ja, das kenn ich, bei mir isses SVN.
    Manchmal ist es nicht möglich, einen sauberen Cut zu ziehen, da kommen halt etwas mehr Dateien zusammen, manchmal sind es nur zwei.
    Ich bin da eher pragmatisch und sage: Mindestens vor dem Mittagessen und vor dem Heimgehen.
    Ansonsten schon mal jede halbe Stunde.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Ich commite in kleinesten Zeitabständen. Jede noch so kleine Änderung wird somit dokumentiert.

    Das heißt ja nicht, dass Du die gleich pushen musst, aber Du hast eine bessere Übersicht für die jeweils betroffenen Klassen.

    Nutzt Du auch CI?

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    Trade schrieb:

    Das heißt ja nicht, dass Du die gleich pushen musst

    Trade schrieb:

    Nutzt Du auch CI?
    Leider bin ich derzeit der einzige in meiner Firma, der Git benutzt, d.h. es handelt sich um ein lokales repository. Von CI bin ich noch meilenweit (oder auch Jahre) entfernt ;( . Achja, aufgrunddessen auch kein push :/ .

    Wenn du also mit ner Änderung innerhalb einer Klasse fertig bist (vorerst) machst du nen commit?
    Naja, kontinuierliche Integration ist auch so sinnvoll. Man sieht halt u. a. direkt, wenn die Änderungen was kaputt gemacht haben und kann entsprechend handeln.
    Also Du pushst Deine Commits nicht auf GitHub, BitBucket o. ä.?

    Und ja, wenn ich eine Änderung vorgenommen habe, dann wird das commited. Natürlich nicht in jeder Klasse einzeln, wenn es mehr oder weniger zusammenhängt. Dann kann man das auch zusammenfassen. Aber sobald es mehrere Schritte sind, sollte man das imho auf jeden Fall unterteilen. Das kommt immer so ein wenig drauf an. Vollkommen unbeachtet bleibt aber, ob es dann vollständig ist oder nicht. Solange die UnitTests noch ausführen ist alles gut. Und wie gesagt, man muss es ja nicht direkt pushen, insofern man das auch online verwaltet.

    tl;dr: Ich commite nicht in bestimmten, festgelegten Zeitintervallen und beschreibe dann in den Details, was passiert ist. Vielmehr richten sich die Commits nach dem, was gemacht wurde / passiert ist.
    Ein Bug Fix, der mehrere Klassen verbindlich einbezieht, wird auch in einem Check-In zusammengefasst. Aber ich mache jetzt keinen, wo drinsteht: "Bug gefixt und das Feature hinzugefügt"

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Trade“ ()

    Ich befinde mich gerade in der Phase von svn zu git und muss sagen, meine History ist totaler Müll (Feierabend-commit) :D Bisher hat mich das nicht stark gestört, aber für die Zukunft sollte sich das bessern.

    Mit dem wechsel zu git, will ich meiner History etwas mehr Aufmerksamkeit schenken, indem ich die ganzen Feierabend-commits in einen Branch werf und wenn das Feature XY fertig/der Bug gefixt ist, den Branch mit gesäuberter History zu einem lauffährigen Build mergen.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „slice“ ()

    Servus,

    also wir arbeiten hier mit SVN. Jeder hat sein lokales Repo, bei Änderungen wird committed und auf der Sandbox upgedated. Updates im Live-System werden höchstens einmal im Monat gemacht. Ich committe nicht jeden Scheißdreck sondern immer dann, wenn das Teilprojekt / meine Aufgabe / das Feature abgeschlossen und komplett durchgetestet ist. Sollte doch mal was sein, kann man ja auf jeden Stand zurückspringen. Zudem habe ich durch PhpStorm eine local history, sodass ich jeden einzelnen Stand von Änderungen an Dateien wiederherstellen kann (jedes mal beim Speichern der Datei wird der Stand gesichert), was äußerst nice ist.

    20+ Files ist jetzt nicht unbedingt viel. Je nachdem was deine Aufgabe ist, wird mal nur an einer Datei eine Änderung gemacht, oder halt auch mal an 70+ Dateien. Wichtig ist halt, dass dein Code gut dokumentiert ist (sollte man nicht schleifen lassen, schon gar nicht wenn man im Team arbeitet - ne halbwegs gescheite IDE unterstützt dich dabei ja eh) und dass du immer eine aussagekräftige Message beim committen hinterlegst für die Änderungen (hier empfehl' ich, ​tsvn:logminsize anzupassen, damit man ohne Eingabe von Änderungsdetails nicht committen kann).


    Link :thumbup:
    Hello World