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.

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.

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.

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.

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:




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:


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.

Okay, danke.
Muss ich mich mal einlesen um überhaupt erst einmal zu verstehen was Trunk Based überhaupt bedeutet.
Aber wahrscheinlich erst ab Montag.

Danke erstmal.

Gruß

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?

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.