js navbar
= GitKompakt
Diese stark verkürzte Einführung richtet sich in erster Linie an Nichttechniker, die in Projekten mitarbeiten wollen oder müssen welche Git zur Versionsverwaltung einsetzen.
== Vorwort
Mit
$ blabla
ist im folgenden immer ein Befehl blabla im Terminal bzw. einer Shell gemeint. Natürlich gibt's auch z.T. ganz hübsche GUIs (u.a. für Mac OS X) - aber da git selbst ein Kommandozeilenprogramm ist und die GUIs meist direkt darauf aufbauen und auch für verschiedene Rechnerplattformen ganz unterschiedlich sind, geht's auf dieser Wikiseite hier in erster Linie um das was immer gleich geht: die Kommandozeile.
Für die meisten Befehle (außer clone) muß man sich innerhalb eines von git verwalteten Verzeichnisses (auch „Arbeitskopie“ genannt, siehe unten) befinden (cd meinprojekt oder noch tiefer drin) - NICHT innerhalb des .git Verzeichnisses. Andernfalls bekommt man von den git Kommandos eine entsprechende Fehlermeldung. Kaputtgehen kann dabei nichts.
Eine ähnliche Beschreibung gibt's auch auf englisch auf der Git Website im Kapitel "Using git for collaboration" im Git Tutorial.
Die hervorragende Dokumentation von http://git.or.cz/#documentation wird damit keineswegs überflüssig - lediglich die Einsteigshürde für Nichttechniker sollte hierdurch entschärft werden. Git kann weit mehr als im Folgenden behandelt wird. Als Einstieg zu den höheren Weihen empfehle ich das Git Tutorial.
==Hilfe!
$ git help
==Wer bin ich? Damit git weiß mit wem es zu tun hat, sollte man sich gleich nach der Installation einmalig vorstellen:
$ git config --global user.name "Your Name Comes Here" $ git config --global user.email you@yourdomain.example.com
==Erstmalig ein fremdes Archiv herunterladen
$ git clone <adresse>
Wobei die Adresse z.B. http://www.meinedomain.de/irgendwas/meinprojekt.git lautet. Auch andere als http:// Adressen sind möglich, Details dazu gibt's im Kapitel "GIT URLS" der git clone Doku.
Mit .git enden die Adressen traditionellerweise, technisch gesehen könnte da auch was anderes stehen.
Ergebnis ist ein neues Verzeichnis mit dem Namen meinprojekt (ohne .git), das sowohl den aktuellen Stand des Projekts (die sogenannte Arbeitskopie) als auch (in einem Unterverzeichnis .git) eine komplette Kopie des gesamten Archivs incl. der vollständigen Versionshistorie in gepackter Form enthält. Das Archiv benötigt erstaunlich wenig Speicherplatz, da sämtliche Veränderungen in extrem platzsparender Weise gespeichert werden.
==Änderungen aus einem fremden Archiv herunterladen
Falls das Archiv, das man per git clone . . . mal geholt hatte inzwischen Neues zu bieten hat, empfiehlt per
$ git pull
diese Neuigkeiten in's eigene Archiv herunterzuladen.
==Versionen im Archiv angucken
$ gitk --all
Möglicherweise ist auch ein auf git aufbauendes Werkzeug eine Hilfe. Im Folgenden geht's aber nur um das „originale“ git - die Kommandozeilenversion.
==Änderungen in's eigene Archiv sichern Vorher gucken was man selbst alles geändert hat:
$ git status
Und ab in's Archiv damit:
$ git commit -a -m "Meine Kurzbeschreibung warum die Version jetzt besser ist als zuvor oder warum ich sie sichern will."
$ git branch
wobei der aktuell aktive Zweig farblich hervorgehoben und mit einem * markiert ist.
==Eine neue Entwicklunglinie (Zweig) beginnen
$ git branch dasneuethema
legt einen neuen Zweig namens dasneuethema an, der auf dem zuvor aktiven Zweig aufbaut. Um wirklich in diesem neuen Zweig zu arbeiten, muß man noch:
==Von einem Zweig zum anderen Umschalten
$ git checkout dasneuethema
schaltet zu einem Zweig dasneuethema um. Wieder zum Hauptzweig kommt man mit
$ git checkout master
Der Zweig „master“ wird ist von Haus aus angelegt und bedeutet die „Hauptentwicklung“, bzw. den produktiven, offiziellen Stand des Projekts.
==Änderungen aus einem Zweig in einen anderen (oder die Hauptrichtung) übernehmen Diese Aktion benötigt zwei git Aufrufe:
$ git checkout zweig_wo_solls_hin
Wenn's in die Hauptentwicklung einfließen soll, steht statt zweig_wo_solls_hin der Zweig master.
Und danach:
$ git merge zweig_wo_kommts_her
==Änderungen in's Projekt publizieren Dazu gibt's verschiedene Möglichkeiten, z.B.:
===Komplettstand per Email
Der Holzhammer ist natürlich die geänderten Dateien per Mail an ein Projektmitglied, das Schreibzugriff auf das Archiv hat welches man sich per git clone geholt hatte zu schicken.
===Änderungen per Email Wesentlich sinnvoller ist, nur die Änderungen per Mail zu verschicken.
Siehe http://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html
===Das eigene Archiv veröffentlichen Diese Möglichkeit dürfte wahrscheinlich am bequemsten sein, da man sich selbst nicht darum kümmern braucht wie die eigene Arbeit genau wieder in's Projekt einfließt.
Dazu genügt es zuerst
$ git update-server-info
aufzurufen und danach den Inhalt des .git Ordners z.B. per FTP auf einen Webserver in z.B. ein Verzeichnis meinprojekt.git hochzuladen und einem Projektmitglied die zugehörige http://... Webadresse zu nennen.
