> Modalitäten > Grundlagen > Arbeitsformen & Organisation > Git für wissenschaftliches Arbeiten: Eine Einführung
Git für wissenschaftliches Arbeiten: Eine Einführung
git (https://git-scm.com) ist eine Versionierungssoftware, die vorwiegend in der Softwareentwicklung eingesetzt wurde, sich aber zunehmend auch steigender Beliebtheit in der Wissenschaft erfreut. Doch was bedeutet Versionierung und warum ist git auch für Studierende schon ein hilfreiches Tool?
Teil 1: Versionierung
Versionierung bedeutet, den Fortschritt der eigenen Arbeit in Versionen zu unterteilen. Um die Softwareentwicklung als Analogie erstmal beizubehalten, nehmen wir an, wir haben ein Tool entwickelt und in der Version 1.0.0 herausgebracht. Also die erste Version, die wir für tauglich halten, von der Öffentlichkeit genutzt zu werden. Es stellt sich dann aber heraus, dass wir einen Fehler eingebaut haben. Den beheben wir noch schnell, damit unser Tool fehlerfrei läuft. Die Versionsnummer steigt dann auf 1.0.1 und zeigt damit an, dass wir einen Patch, in diesem Fall zur Fehlerbehebung, herausgebracht haben.
Warum drei Nummern? Ganz einfach: Die erste Nummer markiert die sogenannte “Major”-Version. Wenn wir also unser Tool grundlegend überarbeiten und in einer offensichtlich neuen Version herausbringen, dann würde die Major-Version sich ändern. Versionen vor der Veröffentlichung werden meist mit 0 bezeichnet. Die zweite Zahl bezeichnet “minor changes”, also geringfügige, aber doch relevante Änderungen in der Funktionalität oder im Design, ohne dass die Software als ganzes überarbeitet wird. Die letzte Zahl bezeichnet “Patches”, also kleine Updates, die z.B. der Fehlerbehebung dienen.
Aber was hilft uns das in der Wissenschaft? Jede:r wird das hier kennen:
Um unsere Arbeit also etwas systematischer zu gestalten und nachvollziehbarer zu machen, welche Datei jetzt konkret welchen Stand der Arbeit enthält, können und sollten wir beginnen, die Dateien zu versionieren. Dabei ist es z.B. möglich, die Dateinamen mit einer Versionsnummer zu versehen. Bei einer Haus-, Bachelor- oder Masterarbeit kann das z.B. bedeuten, dass die Major-Version eine 0 bleibt, bis die Arbeit als Ganzes fertiggestellt wurde, die Minor-Version den Abschluss von Kapiteln beschreibt und die Patch-Zahl markiert, wenn in den Kapiteln gearbeitet wurde. So könnte eine halb fertiggestellte Arbeit etwa die Versionszahl 0.4.6 haben, weil wir vier Kapitel fertiggestellt und am fünften bereits sechsmal gearbeitet haben. Die Dateien sehen so zumindest schon deutlich übersichtlicher aus:
Teil 2: git
git ist eine quelloffene Software, die der Versionsverwaltung dient. Bisher haben wir die Dateien benannt, aber noch nirgendwo verzeichnet, was wir in den einzelnen Schritten getan haben. Dafür können wir jetzt git zu Hilfe nehmen.
In der Softwareentwicklung dient git der Zusammenarbeit und der Verlaufssicherung. git protokolliert Arbeitsstände und weist sie sogenannten “commits” zu, eindeutig mit einer ID versehenen Arbeitsständen, die aktiv getriggert werden müssen. Zu jedem dieser commits gibt es einen kurzen Kommentar, was getan wurde. So kann in einem Team jede:r nachvollziehen, woran die Kolleg:innen gearbeitet haben. Zusätzlich kann git frühere Arbeitsstände wiederherstellen. Wenn also jemand einen Fehler gemacht hat, selbst wenn das schon eine Weile her ist, kann anhand der commit-ID jeder protokollierte Arbeitsstand wiederhergestellt werden. Das ist deutlich komfortabler als etwa die “Rückgängig”-Funktion in Word-Prozessoren.
Aber auch, wenn man allein arbeitet, ist git hilfreich. Man versieht die Versionsschritte mit Kommentaren und macht so für sich selbst nachvollziehbar, was an welchem Punkt getan wurde. Wenn ich z.B. feststelle, dass ich ab einem bestimmten falsch abgebogen bin, aber nicht mehr genau weiß, wann, kann ich einfach das git-Protokoll befragen und mir das sogenannte “log” ausgeben lassen. Darin sind alle Kommentare mit den entsprechenden commit IDs enthalten und ich kann schnell und einfach sehen, an welche Stelle ich zurückspringen muss, um meinen Fehler zu beheben.
Zusätzlich hilft diese Kommentarfunktion dem Fortschrittsgefühl. Gerade bei längeren Arbeiten, ob BA-, MA- oder Doktorarbeiten, kommt es häufig zu einer Phase der Ermüdung, in der man den Eindruck hat, dass nichts voran geht. Durch das Protokollieren der Fortschritte mit git kann man aber offensichtlich sehen, dass etwas passiert und bekommt so ein besseres Gefühl für das, was man bereits geschafft hat. git hilft also gerade beim wissenschaftlichen Arbeiten auch bei Ermüdung.
Aber wie geht das jetzt konkret? In diesem kurzen Tutorial wollen wir uns nur die einfachsten Grundlagen anschauen. git ist ein sehr mächtiges Tool und besitzt eine große Tiefe an Features und Funktionen. Das kann schnell erschlagen und auch erfahrene git-Anwender:innen kommen manchmal an ihre Grenzen. Das sollte uns aber nicht verunsichern, denn die Basis-Funktionen sind denkbar einfach.
Teil 3: Hands On
Zunächst müssen wir git installieren. Man lädt dabei git einfach herunter (https://git-scm.com/downloads) und richtet es sich gemäß den Voreinstellungen ein. Spezielle Einstellungsmöglichkeiten brauchen einen als Anfänger:in nicht zu interessieren. Man kann git sowohl über die Konsole steuern als auch über ein grafisches Interface (https://git-scm.com/downloads/guis). Für beides gelten die gleichen Begriffe, weshalb wir hier kurz die wesentlichen Konsolenbefehle durchgehen. Die Konsole ist ohnehin mächtig und hilfreich, auf ein entsprechendes Tutorial muss an dieser Stelle aber verzichtet werden.
Wir erstellen jetzt einen Ordner und benennen ihn eindeutig nach dem Projekt, beispielsweise BAArbeit . Diesen Ordner öffnen wir, entweder in der Konsole oder in der grafischen Oberfläche, und initialisieren das git-Protokoll für diesen Ordner mit git init . Damit wird git gesagt, dass es die Arbeit in diesem Ordner protokollieren soll.
Jetzt beginnen wir mit der Arbeit. Haben wir einige Dateien angelegt und einiges an Arbeit begonnen, merken wir die neuen Dateien mit git add . für den nächsten commit vor. Der Punkt im Befehl bedeutet, dass der gesamte Inhalt des Ordners vorgemerkt werden soll. Wenn nur eine einzelne Datei hinzugefügt werden soll, kann man diese per git add $name hinzufügen, wobei $name dem Dateinamen entspricht.
Anschließend machen wir unseren ersten commit. Der allererste commit eines Projekts wird meist mit “initial commit” beschrieben: git commit -m "initial commit" . Der Befehl sagt git, dass wir die vorgemerkten Änderungen und Dateien mit dem Kommentar ( -m für den Parameter “message”) versehen committen wollen. git speichert nun den aktuellen Stand unter einer eindeutigen ID mit dem Kommentar, den wir formuliert haben.
Haben wir etwas weiter gearbeitet, können wir dann den nächsten Schritt mit git add . vormerken und mit git commit -m "complete chapter 1" committen. In diesem Fall haben wir git den aktuellen Stand zu Protokoll gegeben mit dem Kommentar, dass wir Kapitel 1 vervollständigt haben. Eine entsprechende Versionsnummer für die Datei, in der wir gearbeitet haben, könnte dann etwa 0.1.0 sein. Die sogenannten “commit messages”, also die Kommentare für den Commit, sollten möglichst aussagekräftig sein, damit man später schnell feststellen kann, was in den jeweiligen Arbeitsschritten gemacht wurde.
Während unserer Arbeit können wir den aktuellen Stand des git-Protokolls jederzeit mit git status abrufen. Damit bekommen wir alle Informationen über protokollierte oder vorgemerkte Änderungen, oder auch, wenn wir einige Dateien vergessen haben. Generell gibt git Auskunft über Probleme, wenn man etwa den add Befehl vergessen hat, bekommt man einen entsprechenden Hinweis. Übrigens, man kann den Prozess auch verkürzen, in dem man einfach git commit -am "nachricht" eingibt. Der Parameter -am bedeutet, dass wir (durch das a ) den git add . Befehl in den commit-Befehl integrieren. git commit -am "nachricht" macht also dasselbe wie git add . und git commit -m "nachricht" .
Mit git log können wir uns den Verlauf unserer Änderungen ausgeben. Dabei sehen wir die commit- IDs, die Kommentare, Datum und Uhrzeit, sowie Urheber:in des commits. Letzteres ist nicht so relevant, wenn man allein arbeitet, in der Zusammenarbeit aber natürlich wichtig. Wollen wir Änderungen rückgängig machen, können wir das am einfachsten mit dem Befehl git reset --hard $ID , wobei anstelle von $ID die ID des gewünschten commits eingegeben werden muss, zu dem wir zurückwollen. ACHTUNG: Dieser Befehl löscht alle Änderungen, die seit dem Ziel-commit gemacht wurden. Eine weniger gefährliche Variante wäre, zu einem alten commit mit git checkout $ID zurückzukehren, allerdings muss man sich dann mit dem Thema des sogenannten “Head” beschäftigen, was etwas komplizierter und eher ein Fall für ein weiteres Tutorial ist.
Fazit
Was haben wir jetzt gelernt? Wir haben gelernt, wie wir Dateien gut versionieren und entsprechend ihrer Versionsnummer benennen. Und wir haben gelernt, wie wir in der eigenen Arbeit mit den grundlegenden Basis-Befehlen unsere Arbeit protokollieren können, um einen besseren Überblick über den Verlauf zu bekommen. Mit einiger Vorsicht können wir auch Änderungen rückgängig machen, in dem wir zu einem älteren commit zurückspringen.
Was wir an dieser Stelle noch nicht besprochen haben, ist, wie wir unsere Änderungen in einem sogenannten “remote” Repositorium sichern können. So ein Repositorium kann zum einen dafür genutzt werden, die eigene Arbeit online zu speichern, um sie etwa auf verschiedenen Geräten bearbeiten zu können, oder aber um mitanderen Leuten zusammen zu arbeiten. Man bekommt solche Repositorien in den meisten Institutionen über die Rechenzentren oder IT-Abteilungen (https://gitlab.rrz.uni-hamburg.de). Unabhängig davon gibt es Anbieter wie Codeberg (https://codeberg.org), die als non-profit Organisation ein git-Repositorium anbieten, oder GitHub (https://github.com), das de facto der größte Anbieter von git-Repos ist und von Microsoft betrieben wird. Stellt man die Sichtbarkeit solcher Repositorien auf privat kann im Übrigen auch niemand anderes den Inhalt sehen. Die wichtigsten Begriffe für die weitergehende Recherche sind hier git clone zum “Klonen” bestehender Remote-Repositorien, git pull, um den aktuellen Stand der Arbeit vom Remote-Repositorium herunterzuladen und git push, um den aktuellen Stand der Arbeit nach dem commit in das Remote-Repositorium hochzuladen.
Dabei kann es aber zu sogenannten Konflikten kommen, wenn etwa vergessen wurde, zu Beginn der Arbeit mit git pull den aktuellen Stand herunterzuladen, dann aber versucht wird, mit git push den lokalen Stand hochzuladen. Das Konfliktmanagement bei git ist aber ein größeres Thema für sich. Im Internet gibt es hierzu aber auch zahlreiche Tutorials und Hilfestellungen
Für die eigene Arbeit an der Master- oder Doktorarbeit, oder auch einfach um eine bessere Struktur und Übersicht über den Arbeitsstand in einem Ordner zu bekommen, reichen die hier aufgeführten Befehle aber erstmal aus. Wer hier spielerisch weiterlernen möchte, sollte sich das Spiel “Oh my git” (https://ohmygit.org) anschauen, das niedrigschwellig an verschiedene Funktionen von git, auch z.B. an sogenannte “branches”, und auch an den Umgang mit Konflikten, heranführt.
INHALT
THEMENFELD GRUNDLAGEN:
SCHLAGWORTE:
CREDITS:
DOI:
In Erstellung
VERSION:
1.0.0.
ZITIEREN ALS:
Müller-Laackman, Jonas (2024). Git für wissenschaftliches Arbeiten: Eine Einführung http://doi.org/ – in Erstellung
