Diskussionsthread: Git: Grundlagen, Branches, Best-Practices und mehr

  • Allgemein

Es gibt 10 Antworten in diesem Thema. Der letzte Beitrag () ist von siycah.

    Diskussionsthread: Git: Grundlagen, Branches, Best-Practices und mehr

    ausgelagert aus Git - Grundlagen, Branches, Best-Practices und mehr ~VaporiZed

    @siycah
    mal ne frage zu dem Remote Verzeichnis bzw, Git- Server. Kann das auch ein einfaches Verzeichnis sein ? Sprich Serverlos ? Nutze zur Zeit Subversion, da geht das nämlich.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „VaporiZed“ ()

    Moin @Coldfire,

    Du kannst natürlich ausschließlich das local Repo benutzen, dort committen, taggen, branchen, etc. Das tust du ohnehin alles lokal.
    Der Git-Server bietet dir allerdings noch einige weitere Vorteile; z.B. dass du deinen Code von überall sehen und tracken kannst.

    Wenn es dir darum geht, dass du deinen Quellcode nicht veröffentlichen möchtest: GitHub bietet dir dauerhaft kostenlose, private Repos an.
    Bei Azure DevOps gibt's ebenfalls einen kostenfreien Plan, mit dem bis zu fünf Benutzer kostenlos die Dienste nutzen können inkl. Git, Boards, Pipelines und Artefakte.

    Es ist aber auch sehr einfach, einen eigenen Git-Server zu hosten. Das habe ich beispielsweise auch für einen Kunden eingerichtet, da wird GitLab verwendet.
    Quellcode lizensiert unter CC by SA 2.0 (Creative Commons Share-Alike)

    Meine Firma: Procyon Systems

    Selbstständiger Softwareentwickler & IT-Techniker.
    M.E. ist Git für alles sinnvoll, bei dem man Versionen von Text-Dateien nachvollziehen möchte.

    Leider ist dies mit VBA in Office-Dateien nicht möglich.

    Ein aktuelles positives Beispiel aus dem MS Universum: Power BI Dashboards lassen sich jetzt auch als Text-Dateien abspeichern und damit ist eine Versionskontrolle möglich.
    NB. Es ist doch schön, wenn man lesbare Namen vergibt. Siehe auch [VB.NET] Beispiele für guten und schlechten Code (Stil).

    INOPIAE schrieb:

    Leider ist dies mit VBA in Office-Dateien nicht möglich.
    Ich hatte vor Jahren mal ein riesiges VBA-Projekt mit Hunderten von Excel-Dateien
    (war so vorgegeben), alle mit einer definierten Struktur von VBA-behafteten Worksheets, Modulen und Klassen.
    Beim Speichern wurden alle Code-Elemente in eine Verzeichnisstruktur als Textdateien abgespeichert.
    Daran hing ein GIT.

    Irgendwann hat Microsoft aber den dafür notwendigen Zugriff auf das VBAProject-Objekt als Sicherheitsrisiko eingestuft und man musste über Policies den Zugriff freischalten.

    Es ist also durchaus möglich, aber erfordert Klimmzüge.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    INOPIAE schrieb:

    ist Git für alles sinnvoll

    INOPIAE schrieb:

    von Text-Dateien


    Grundsätzlich kann man mit Git alles versionieren. Sofern der Git-Server auch LFS unterstützt, können auch (sehr) große Datenmengen versioniert werden (mehrere GiB).
    Es ist nicht gerne gesehen, wenn man in einem Code-Repo Binaries versioniert - ist auch Blödsinn. Bilder, PDFs und andere Dokumentenformen wiederum sind Gang und Gäbe.

    Sobald es darum geht, Binaries zu versionieren, sollte man an CI/CD denken, bspw. mit Azure DevOps, GitLab oder wie in meinem Fall Gitea, was ich für die Verwaltung, Versionierung und das Testen von meinen und Kundenprojekten verwende.
    Die Artefakte aus den Pipelines können "versioniert" gespeichert werden, sodass man immer auf einen Stand X Zugriff hat. In dem Fall muss man nur schauen, dass man genügend Speicherplatz hat.

    INOPIAE schrieb:

    Ein aktuelles positives Beispiel aus dem MS Universum


    Es ist natürlich immer gut, wenn solche Sachen auf Textbasis ex-/importiert werden können, allerdings können die meisten Git-Server relativ gut mit bekannten Dateitypen umgehen, was auch in der Hinsicht eine super Verbesserung gegenüber vorigen Jahren ist.
    Quellcode lizensiert unter CC by SA 2.0 (Creative Commons Share-Alike)

    Meine Firma: Procyon Systems

    Selbstständiger Softwareentwickler & IT-Techniker.
    Grüße,

    ich habe ein größeres Projekt das immer wieder größere Änderungen und zwischen durch auch mal kleinere Fehlerkorrekturen erfährt.
    Jetzt könnte man ja auf die Idee kommen einen Feature-Branch anzulegen in dem man losgelöst vom Master-Branch die größere Änderung entwickelt.

    master
    |-- feat/restehandling

    Taucht jetzt während der Feature-Entwicklung ein Problem im Programm auf das man schnell beheben kann und muss, würde ich jetzt auf dem Master-Branch ein Bugfix-Branch erstellen

    master
    |-- feat/restehandling
    |-- bug/statistik

    Jetzt hat man 2 Branches neben dem Masterbranch die sich alle von einander unterscheiden.
    Wie handle ich das, damit am Ende der Feature-Entwicklung auch den Bugfix im Featurebranch habe?

    Ist der Bugfix abgeschlossen, Merge ich diesen in den Master-Branch und lösche den Bugfix-Branch.

    Wenn ich dann später mit dem Feature-Branch fertig bin und diesen in den Master-Branch mergen möchte, bekomme ich aber einen Konflikt.
    Wie löse ich dieses Problem?

    In den Feature kann ich den Bugfix ja auch nicht mergen, auch da käme dann eine Konfiktmeldung. Außerdem hätte ich Bug 1 ja dann immer noch im Master solange ich den Feature nicht zurück gemerged habe.
    @Montoyafan

    Je nach Projektgröße muss man schauen, welches Branching-Modell man verwendet.
    ME. gibt es zwei, die man berücksichtigen sollte.

    Das wären einmal GitFlow und Trunk-Based.

    Bei sehr großen Softwaresystemen mit langsamen/langen Releasezyklen bietet sich das GitFlow-Branching-Modell an, während bei Software mit schnellen Releasezyklen (z.B. Web-Projekte) man eher auf Trunk-Based Development setzen sollte.

    Je nachdem, für welches Modell man sich entscheidet, hat man dein besagtes Problem gar nicht mehr, oder es ist sehr einfach in der Handhabung.

    Voraussetzung für beide Modelle ist, dass CI/CD verwendet wird - was allerdings so oder so eingesetzt werden sollte, wenn man heutzutage Software entwickelt.

    Anbei ein Ausschnitt eines Dokuments, was ich ebenfalls meinen Kunden zur Verfügung stelle.




    GitFlow
    Das Gitflow findet Verwendung bei größeren Projekten, vornehmlich Applikationen, die direkt auf Kundenmaschine Einsatz finden.Es wird mit folgenden Branches/Branchtypen gearbeitet:

    Branch-NameBranch-TypBeschreibung
    masterRelease-BranchDieser Branch enthält alle Release-Versionen, die zum Kunden ausgeliefert werden. Es findet keine Entwicklung auf diesem Branch statt!
    release (opt)Release-BranchDieser optionaler Branch kann parallel zum master Branch geführt werden. Beide Branches sollten jedoch immer den gleich Stand haben.
    develInstabiler Entwicklungs-BranchDieser Branch enthält möglicherweise instabile Versionen, die getestet werden (können), wie RCs. Features, Fixes und Hotfixes können hierein gemerged werden.
    feat/*Feature-BranchDiese Branches werden genutzt, um neue Features so zu entwickeln und testen, bevor sie in den devel Branch gemerged werden.
    fix/*
    Fix-BranchDiese Branches werden genutzt, um nicht-kritische Bugfixes zu entwickeln und testen, bevor sie in den devel Branch gemered werden.
    hotfix/*
    Hotfix-BranchDiese Branches werden genutzt, um schwerwiegende Bugs aus dem release/master Branch zu fixen. Sie werden zunächst wieder in devel gemerged.



    Anbei noch eine bildliche Darstellung von dem Branching:
    (Quelle: atlassian.com/git/tutorials/co…orkflows/gitflow-workflow)


    Trunk-Based Workflow

    Das Trunk-Based Workflow findet bei kleineren Projekten und Bibliotheken Einsatz, wo kürzere Entwicklungszyklen benötigt werden, weil potenziell mehrere Projekte davon abhängen.
    Es wird mit folgenden Branches/Branchtypen gearbeitet:

    Branch-NameBranch-TypBeschreibung
    masterRelease-BranchDer master bildet den Stamm und wird in kurzen Zyklen erweitert. Der master ist immer stabil!
    feat/*Feature-BranchKurzlebige Feature-Branches werden verwendet, um kleine Features zu entwickeln. Sie werden direkt in den master gemerged.
    fix/*Fix-BranchKurzlebige Fix-Branches werden verwendet, um Fehler und Bugs zu beheben. Sie werden direkt in den master gemerged.

    Bildliche Darstellung von dem Branching:
    (Quelle: statusneo.com/trunk-based-development/)


    Branch-Namen

    Aufgrund eines kulturellen Wandels in der Softwareindustry kann der master-Branch auch main genannt werden.

    Grundsätzlich sollten alle Branches einen sinnvollen Namen tragen, bspw. mit einer kurzen Beschreibung der neuen Funktion, des Fixes, etc.
    Branch Namen sollten zusätzlich dazu im kebap-case und auf englisch geschrieben werden.

    Branch Naming: ✅
    • IDs von Tasks
    • Kurze Beschreibung des Features oder Fixes
    • Englische Namen
    • lower-kebap-case

    Branch Naming: ❌
    • Umlaute
    • Nur Zahlen
    • Keine Beschreibung des Features oder Fixes
    • (...)

    Beispiele für gute Branch Namen:
    • feat/add-new-nav-item ✅
    • fix/1324-fix-segfault-on-config-load ✅
    • hotfix/fix-crash-on-save ✅

    Beispiele für schlechte Branch Namen
    • fix ❌
    • fix_bug ❌
    • öiuqebfvw ❌
    • fix/AbsturzVonDingbeheben ❌


    Pull Requests

    Unabhängig vom Branching Modell werden PRs (Pull Requests) für Merges geöffnet.
    Pull Requests dienen dazu, vor dem Aktualisieren der mögliche Fehler im Code zu finden.
    Gleichzeitig dienen sie auch als Möglichkeit, einen Code-Review durch die Kollegen des Teams durchführen zu lassen.
    So werden handwerkliche und logische Fehler schneller im Quellcode gefunden; das gewonnene Feedback dient auch der Qualitätssteigerung des Codes.

    Voraussetzungen für einen Pull Request

    Bevor ein PR geöffnet werden kann, müssen folgende Voraussetzungen erfüllt sein:
    • Ist das Feature/der Fix vollständig implementiert, oder soweit, wie es die Aufgabe vorsieht?
    • Sind die lokalen Tests erfolgreich durchgelaufen?
    • Wurden alle Branches und Stände committet?
    • Sind noch TODOs im Code offen? Wenn ja: wieso wurden sie noch nicht erledigt?
    • Gibt es potenzielle Merge-Konflikte mit dem darüberliegenden Branch, die vorher behoben werden müssen?
    • Wurde das CHANGELOG angepasst?

    Gute PRs schreiben

    Ist der Code soweit geschrieben, dass er dem Skrupel anderer Entwickler ausgesetzt werden kann, kann der Pull Request selber geöffnet werden.
    Pull Requests sollten folgende Kriterien erfüllen:
    • Aussagekräftiger Titel
    • Es muss eine Pipeline getriggert werden
    • Der PR-Text sollte zumindest eine Auflistung der Commits enthalten


    Code Reviews

    Code Reviews sollten bei jedem PR durchgeführt werden, sodass möglichst kleine Änderungen im Gesamtcode untersucht werden können, ohne dass der Überblick verloren geht.
    So können kürzere Releasezyklen eingehalten werden, ohne dass mehrere Entwickler stundenlang durch ein Code-Review blockiert sind.

    Auswahl der Reviewer

    Jeder PR sollte mindestens von einem weiteren, möglichst projekt-fremden, Kollegen aus dem Team geprüft werden.
    So wird sichergestellt, dass Entscheidungen zur Programmierung aus einem anderen Blickwinkel betrachtet werden.




    Hat man sich an diese Regeln gehalten und alle Prozesse befolgt/Fragen positiv beantwortet, kann dein Problem schon gar nicht mehr auftauchen.
    Quellcode lizensiert unter CC by SA 2.0 (Creative Commons Share-Alike)

    Meine Firma: Procyon Systems

    Selbstständiger Softwareentwickler & IT-Techniker.
    Die Erkärung findet sich in dem obigen Beitrag.

    Das Trunk-Based-Development ist nur eine andere Art zu sagen, dass man auf Basis des masters entwickelt.

    Die Beispielbilder sind gut zur Veranschaulichung.
    Sind bei dir denn CI/CD im Einsatz?
    Quellcode lizensiert unter CC by SA 2.0 (Creative Commons Share-Alike)

    Meine Firma: Procyon Systems

    Selbstständiger Softwareentwickler & IT-Techniker.
    Ich arbeite alleine, nicht in einem Team.
    Ich verwende Github aktuell eigentlich primär zur Sicherung, weniger zur Versionsverwaltung.

    Wenn ich etwas größeres, das ein paar Tage oder Wochen braucht, implementieren möchte, erstelle ich mir in der Regel physisch auf dem PC einen Klon und trage dann quasi von Hand evtl. Bugfixe in beide Versionsstände ein.
    Das ist aber alles mit zunehmender Größe sehr aufwendig und natürlich auch Fehleranfällig. So habe ich oft Bugs wieder ins Hauptprogramm eingeschleust die ich in der "Master-Version" schon behoben hatte, weil ich sie nicht oder nur unvollständig in die "Feature-Version" eingefügt habe.
    Genau solche Probleme hat man natürlich dann mit einer Versionsverwaltung nicht.

    Auch wenn du alleine programmierst und nicht im Team, solltest du zumindest statische Code-Analysen durchführen. Dann am besten auch automatisiert in Pipelines.
    Bei GitHub sind die glaube ich nicht im vollem Umfang verfügbar, wenn die Repos privat sind - es gibt aber noch andere Lösungen, als GitHub, wo das möglich ist.

    Grundsätzlich solltest du allerdings folgende Strukturen in deinen Repos vorfinden:

    Quellcode

    1. /
    2. .gitignore # committe keine unnötigen Dateien!
    3. README[.md] # schreibe hier alle wichtigen Informationen rein. Auch wenn du alleine arbeitest, macht es dein Leben einfacher
    4. LICENSE[.md] # eher für geteilte Repos wichtig, aber auch für dich um zu wissen, wie du deine Software lizensiert hast


    Montoyafan schrieb:

    primär zur Sicherung, weniger zur Versionsverwaltung.

    Alleine die Tatsache, dass du deinen Code sicherst zieht eine Versionsverwaltung nach/mit sich. Du verwendest es schon ganz richtig. Es geht darum, alle Stände zu haben, damit man bei Änderungen sehen kann, wo/was schief gelaufen ist.

    Montoyafan schrieb:

    weil ich sie nicht oder nur unvollständig in die "Feature-Version" eingefügt habe.

    Folgst du den Regeln oben, kann dir das nicht passieren.

    Indem du immer den überliegenden Branch in deinen Feature/Fix Branch reinziehst, siehst du direkt wo es knallt/knallen könnte.

    Im Prinzip musst du wenn es ums Branchingmodell geht folgendes beachten: master und release sind immer stabil. Sie bauen durch und sind feature-complete und durchgetestet.
    ​devel, ​feat/*, ​fix/* Branches sind grundsätzlich instabil. Auch wenn sie es nicht sind. Diese Branches musst du immer so betrachten, dass sie jederzeit wie eine Bombe hochgehen könnten.
    Quellcode lizensiert unter CC by SA 2.0 (Creative Commons Share-Alike)

    Meine Firma: Procyon Systems

    Selbstständiger Softwareentwickler & IT-Techniker.