Eine gute Übersicht für Git-Neulinge aus dem Subversion-Land gibt es hier zu sehen. Da für mich für den direkten Quereinstieg nur eine Handvoll der Befehle wichtig waren, hier eine kurze Übersicht ohne Anspruch auf Vollständigkeit.
git remote add origin http://rechner.net/repository.git git remote add mirror git@mirror.org/repository-mirror.git git pull origin master git branch experimental git checkout experimental git add neuedatei.txt git rm foobar.exe git commit -m "Dinge geändert." git push mirror experimental git checkout master git merge experimental
Was es mit alledem auf sich hat und noch einiges mehr, steht in den folgenden Abschnitten.
Neues Git-Repository anlegen
Das ist ein Einzeiler:
git init
Anders als Subversion verwaltet Git das Repository in einem einzelnen .git-Verzeichnis im Projektroot. Innerhalb dieses Verzeichnisses liegt auch eine Datei Namens config, die die projektspezifischen – Vorsicht: lokalen! – Einstellungen beinhaltet.
Soll das Repository nur als „externer“ Datenspeicher, nicht aber als Arbeitskopie dienen, kann das Repository als sog. Bare-Repository mit dem Flag --bare angelegt werden:
git init --bare
Projekt auschecken und updaten
Um das Projekt initial auszuchecken (svn checkout) wird der Befehl git clone benutzt. Das Klonen erzeugt eine Kopie des ausgewählten Repositories im angegebenen Zielordner. Wird kein Ordner angebgeben, wird der Name des Repositories als Ordnername gewählt.
git clone git://url.zum/repository zielordner
Repositories können entweder lokal als Dateipfad oder entfernt per http://, git:// oder ssh:// addressiert werden. Wie man dabei Schreibarbeit spart steht im nächsten Abschnitt über Remotes.
Ist ein Projekt bereits ausgecheckt und soll nur auf den neuesten Stand gebracht werden (svn update) wird der Befehl git pull benutzt.
git pull
Dieser Befehl ist eine Kurzform von git fetch name-eines-branches, gefolgt von git merge name-eines-branches, wobei als Name des Branches der aktuell angewählte Branch verwendet wird. Nach einem, initialen clone heißt dieser Branch master.
Remotes
Damit es nicht immer nötig ist, die volle URL eines externen Repositories anzugeben, lassen sich sogenannte remotes einrichten. Nicknames, wenn man so will:
git remote add name-des-remotes http://url.zum/repository
Danach ist es etwa möglich, den Master-Branch des Repositories einfach mittels:
git pull name-des-remotes master
zu behiehen. Die offizielle Quelle eines Repositories – so vorhanden – wird typischerweise als origin bezeichnet.
Historie und Änderungen anzeigen
Änderungen lassen sich mittels git status und git diff anzeigen, die Historie erhält man mittels git log.
git status git diff git log
Dateien hinzufügen, löschen, verschieben, kopieren, ignorieren …
Die Befehle svn add (hinzufügen), svn rm (löschen), svn cp (kopieren) und svn mv (verschieben) haben in Git nur zwei Gegenparts:
git add Dateiname git rm Dateiname git mv AlterDateiname NeuerDateiname
Da Git Inhalte, nicht Dateien trackt gibt es für das Kopieren keinen explizitenn Befehl – Git erkennt diese Operation prinzipiell selbstständig. Es ist allerdings relevant, dass kopierte wieder per git add svn add NeuerDateiname hinzugefügt werden; Von Hand verschobene Dateien müssen per svn del AlterDateiname zusätzlich als gelöscht markiert werden. Es ist dabei egal, ob dieser Aufruf im betroffenen Ordner oder höher in der Hierarchie erfolgt.
Um Dateien zu ignorieren, wird in dem Ordner, ab dem die Ignorier-Regeln gelten sollen eine Datei namens .gitignore angelegt. Diese beinhaltet Zeilenweise Datei- oder Ordnernamen, welche auch Wildcards in Form des Sternchens enthalten können. Beispiel:
*.exe .deleteme
Da Dateien mit führendem Punkt unter Windows nicht direkt im Explorer angelegt werden können, kann man sich behelfen, indem man die Datei gitignore.txt nennt und dann in der Kommandozeile wie folgt umbenennt:
mv gitignore.txt .gitignore
Änderungen einchecken
Sollen Änderungen eingecheckt werden (svn commit) wird der Befehl git commit benutzt. Zuvor müssen geänderte Dateien – auch, wenn sie bereits dem Projekt zuvor bereits hinzugefügt wurden – per git add als staged markiert werden.
Anders gesagt: Es obliegt dem Benutzer, auszuwählen, welche Änderungen eingecheckt werden sollen.
git add Datei1 Datei2 Datei3 git commit
Sollen alle Änderungen commited werden, gilt folgender Shortcut:
git add . git commit
Oder ganz einfach:
git commit -a
Das Staging von Dateien ist eine nicht zwingend triviale Angelegenheit, erlaubt aber sehr interessante Kniffe – etwa das teilweise Einchecken einer geänderten Datei. Mehr dazu (und zum Problem der verwurschtelten Änderungen) im Artikel The Thing About Git.
Alle Änderungen verwerfen
Um wirklich alle Änderungen seit dem letzten commit radikal zu verwerfen, kann git reset mit dem Parameter --hard verwendet werden.
git reset --hard
Mehr dazu (und zum Korrigieren bereits eingecheckter Änderungen) im Git Book im Kapitel Undoing in Git.
Änderungen an ein Repository pushen
Da Git dezentralisiert läuft, gibt es kein zentrales Repository wie bei Subversion. Sollen die Commits dennoch an ein bestimmtes Repository geschickt werden – etwa, um einen pseudozentralen Workflow nachzubilden – verwendet man den Befehl svn push.
git push [name-des-remotes] [branch]
Vorsicht: Man sollte es unterlassen, an Repositories zu pushen, die nicht mittels git init --bare (Bare-Repository) angelegt wurden!
Branching, switching und merging
Ein Branch wird ähnlich in Subversion mittels git branch erzeugt, das Switchen geschieht allerdings per git checkout:
git branch neuer-branch git checkout neuer-branch
Vor einem Checkout müssen alle Änderungen commited sein; Ist das nicht erwünscht, hilft die Technik des stashings.
In welchem Branch man sich befindet und welche Branches lokal verfügbar sind (d.h., wenn sie mit git fetch oder git pull gezogen wurden), lässt sich mittels git branch ohne Parameter anzeigen:
git branch
Soll ein bestehender Branch in den aktuellen gemergt werden, verwendet man – naheliegend – git merge:
git merge zu-mergender-branch
Alternativ kann man den bereits bekannten Shortcut git pull benutzen, wenn es sich um ein entferntes Repository handelt:
git pull git://url.zum/repository zu-mergender-branch git pull name-des-remotes zu-mergender-branch
