Kurzanleitung für Git

Hinweis: Der Austausch von Daten auch zwischen den eigenen Rechnern über Git hat gegenüber dem Kopieren den Vorteil, dass man nie versehentlich eine neue Version mit einer alten überschreibt. Leider ist das beim häufigen Kopieren unvermeidbar.

Hinweis: Das Archivieren mittels Git dient auch als Backup. Damit erübrigen sich in der Regel weitere aufwendige Backuplösungen. Damit ist git Ideal geeignet zur Verwaltung von Abschlussarbeiten, die in LaTeX verfasst werden.

Herunterladen und "Fork" eines Repository von Bitbucket oder Github

Heruntergeladen wird ein Repository mit dem Kommando

git clone git@bitbucket.org:guidokanschat/amandus.git
falls man auf Bitbucket registriert ist und ein SSH-Schlüssel dort gespeichert ist, oder ansonsten
git clone https://guidokanschat@bitbucket.org/guidokanschat/amandus.git

Bitbucket und Github sind zwei Webseiten, auf denen man Repositories für eigene Projekte anlegen kann. Dabei hat ersteres den Vorteil, dass man, wenn man sich mit einer Uni-Adresse registriert, kostenlos nicht-öffentliche (private) Projekte anlegen darf.

Den Befehl git clone ruft man auf jedem Rechner für jedes gewünschte Arbeitsverzeichnis nur einmal auf. Danach geht es dann unten mit dem Arbeitszyklus weiter.

In der Regel bekommt man kein Schreibrecht auf ein Repository, das gemeinschaftlich benutzt wird. Um aber auch für eigene Weiterentwicklungen Git benutzen zu können, muss man daher erst eine "fork" in einem eigenen Repository anlegen. Bei Bitbucket ind Github geht das über die Webseite.

Arbeitet man an einem Projekt mit "fork", so ist es nötig, sowohl mit dem Stammprojekt als auch mit dem eigenen zu synchronisieren. Dazu sieht das Anlegen eines Arbeitsverzeichnisses (nach Anlegen der "fork" auf Bitbucket) etwa so aus:

git clone git@bitbucket.org:yourname/amandus.git
cd amandus
git remote add upstream git@bitbucket.org:guidokanschat/amandus.git

Hinweis: Entwickelt man in einem Gemeinschaftsprojekt, so sollte der "Branch" master nur für updates von den Repositories, möglichst durch git rebase benutzt werden. Es ist dringend anzuraten, alle eigenen Entwicklungen auf Seitenzweigen zu machen.

Arbeitszyklus

Der tägliche (oder besser stündliche) Arbeitszyklus mit Git sieht wie wie folgt aus:

git fetch --all
git rebase edit what ever you want
git commit -am 'I did these things'
edit until done for a bit

git commit -am 'I achieved these things'
git status
git push

git fetch --all lädt die neuesten Versionen von allen Servern, die mit git remote add angegeben wurden. Diese stehen dann zur Verfügung, werden aber nicht automatisch auf die lokalen Zweige kopiert. Das macht git rebase. Benutzt man ein Repository, zum Beispiel für die Examensarbeit allein, so kann man die ersten Zeilen auch durch git pull ersetzen.

Wichtig: Erst mit dem letzten Kommando werden diese Änderungen auf den Server übertragen und stehen damit für git fetch auf anderen Rechnern zur Verfügung.

Ein weiteres nützliches Kommando ist git status, was angibt, welche Daten noch nicht im Repository sind. Dateien, die von Git bisher nicht verwaltet werden, müssen mit git add hinzugefügt werden.

Pflege der "fork"

Hat man eine "fork" angelegt, so wird diese nicht automatisch mit dem zentralen Repository synchronisiert. Dazu gibt es eine kleine Abwandlung des Zyklus:
git fetch --all
git checkout master
git rebase
git rebase upstream
git status
git push

Der Befehl git fetch erzeugt dabei neben anderen auch Ausgaben der Form

[...]
99bc6ff..dea4818 master -> origin/master
[...]
745b144..93c0925 master -> upstream/master

Sind dabei die jeweils hinteren Nummern, also hier "dea4818" und "93c0925" gleich, so ist die "fork" aktuell, und man kann sich die weiteren Schritte sparen. Hier ist das nicht der Fall.

Weitere Informationen

Sehr gute Texte zur Benutzung von von Git, insbesondere über typische Arbeitsabläufe und Arbeitsorganisation findet man bei Atlassian. Unbedingt lesenswert!