Versionierung: Git

Meine Tipps / Bestrebungen

Womit ihr euch bei Git dringend beschäftigen solltet:

• Commits

  • Schreibt sinnvolle Commit-Messages und committet in sinnvollen Portionen - nicht zu häufig und nicht zu selten, aber lieber einmal zu viel ;)
    Optimalerweise sollte ein Commit ein Thema behandeln.

  • Comittet so wenig Binaries (.pdf, .png, .xls, .doc ... - alles was kein Text ist) wie möglich und vor allem keine ständigen Änderungen daran. Git speichert bei jedem Commit die Unterschiede. Das geht bei Text (auch .csv z.B.) sehr gut, aber jedes komprimierte Dateiformat muss jedes mal komplett neu gespeichert werden.

  • Nutzt Large File Storage, falls ihr Daten speichern wollt (läuft teilweise schon automatisch).

• Merges

  • Nutzt git pull --rebase um eine aufgeräumte und Nachvollziehbare Struktur zu haben.

  • Lernt mit Konflikten umzugehen (am einfachsten in einem Software-Tool). Dafür ist Git da!

• Nutzt Submodules und schreibt allgemeinen Code den ihr mehrfach verwenden könnt.
  Hier noch Details für Python Nutzer.

• Haltet euch an eine grobe Struktur

  • Der Master-Branch hat nur funktionierende Feature und wird nicht zur Entwicklung genutzt

  • Jedes neue Feature wird in einem Branch entwickelt und getestet. Wenn man sicher ist, dass es nichts kaputt macht kann man es dann in den Master mergen.

    • Profis nutzen hier wohl teilweise die "Patch" funktion und sorgen so dafür, das Merges nie zum Master führen, aber mindestens für meine bisherigen Projekte finde ich es mit normalen Merges schöner.

    • Ändert möglichst nicht zu viel auf einmal, vor allem wenn ihr mit anderen zusammen arbeitet.

Die wichtigsten Befehle (Ohne Erklärung)

Die Liste ist nur als Erinnerung gedacht, zum Verstehen könnt ihr einfach auf den einschlägigen Seiten suchen.

• git clone <RepoLink> <opt:Foldername>

• git commit -m "<Message>"

• git push

• git pull --rebase

• git checkout -b <BranchName>

•  git reset --hard HEAD

• git submodule add <RepoLink>

• git submodule update --init

Literaturverwaltung

Git lässt sich nicht nur für Programmcode verwenden. Verwaltet ihr eure Literatur in einer BibTex- oder vergleichbaren Datenbank, könnt ihr die Datenbank sauber versionieren und alle PDFs direkt mit im Ordner lagern. Dank Large File Storage (LFS) werden PDFs mit versioniert, aber separat gespeichert.

Wenn ihr die Datei ".lfsconfig" mit dem folgendem Inhalt einfügt, werden die PDFs bei einem Clone nicht automatisch herunter geladen:

So könnt ihr das Literatur Repository entspannt in diverse LaTeX oder andere Repositories einbinden (wo ihr auf die Datenbank, aber nicht zwingend auf die PDF zugreifen wollt), ohne dabei Speicherplatz zu verschwenden.
Braucht ihr dann doch mal ein PDF könnt ihr mit den folgenden Befehl einzelne oder all PDF herunterladen:

Simple Homepage/Wiki

Falls ihr eine einfache Homepage erstellen wollt, oder z.b. eure Wiki zugänglich machen wollt, hilft euch mdwiki um dies mit MarkDown Dateien in einem Repository umzusetzen.

Auf Gitlab könnt ihr das sehr einfach hosten: Versichert euch, dass Pages eingeschaltet sind und macht am besten einen Fork von diesem Repository.

Wichtig ist die Datei ".gitlab-ci.yml" mit etwa dem folgenden Inhalt:

Diese wird nach jedem Commit auf den Master automatisch ausgeführt und publiziert die Dateien im Ordner public. Die Adresse findet ihr in den Pages Einstellungen nach dem ersten Durchlauf..
Im Ordner "public" sollte sich eure "index.md" und "navigation.md" befinden sowie die "index.html" von mdwiki und eine "config.json" wo ihr z.b. den Titel ändern könnt.

Stolpersteine

Für viele sind die verschiedenen Dinge die man mit Git tuen kann anstrengend und beängstigend unklar. Wenn man allerdings einmal das Grundprinzip verstanden hat und sich die Mühe gemacht hat die wenigen relevanten Befehle auszutesten, dann braucht man auch nach langer Zeit im Zweifel immer nur kurz die Syntax zu checken.

Allgemeine Konflikte

Man kann sich gerade bei einem Rebase oder Merge häufig in (dem Anschein nach) schwierige Situationen manövrieren. Mit etwas googeln kommt man in der Regel allerdings auch schnell wieder raus.

Für Anfänger (und generell wer ganz auf Nummer sicher gehen möchte) empfiehlt es sich am besten vor nem größeren Eingriff zu pushen oder im Zweifel einfach den Ordner zu kopieren. In der Regel kann man allerdings mit  den unterschiedlichen Möglichkeiten von "git reset" das meiste einfach nochmal wieder zurück nehmen und nochmal anders testen. Hier ist allerdings vorsicht geboten, wer zu viel und hart resettet braucht ggf. mehr Mühe wieder an seine Daten und vor allem Struktur heran zu kommen und es gibt sicherlich auch Fälle in denen das keinem Profi mehr gelingt.

Das normale lösen von Merg-Konflikten ist übrigens kein Problem von Git, sondern sollte eigentlich leicht von der Hand gehen, wenn man:

• notwendige Merges vorher bedenkt und ggf. schrittweise vorbereitet

• und vor allem Branches nicht meilenweit divergieren lässt, weil man Angst vor nem Merge und den Konflikten hat.

R (RStudio)

Unterstützt keine Submodules ... Nutzt statt RStudio die Kommandozeile odern nen anderes Tool zum organisieren des Gits, bevor ihr auf Submodules verzichtet.Ihr könnt auch ein Projekt aus dem Submodule erstellen und dann hin und her springen.