Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- orga:gitkompakt [2009/05/06 21:43] – Externe Bearbeitung 127.0.0.1
+++ orga:gitkompakt [2010/01/10 02:36] (aktuell) – mro
@@ Zeile 1: / Zeile 1: @@
-Die Seite ist in mein privates Wiki umgezogen: http://wiki.mro.name/playground/gitkompakt
+~~ODT~~
+= GitKompakt
+Diese stark verkürzte Einführung richtet sich in erster Linie an Nichttechniker, die in Projekten mitarbeiten wollen oder müssen welche [[http://de.wikipedia.org/wiki/Git|Git]] zur [[http://de.wikipedia.org/wiki/Versionsverwaltung|Versionsverwaltung]] einsetzen.
+== Vorwort
+Mit
+<code>
+$ blabla
+</code>
+ist im folgenden immer ein Befehl ''blabla'' im [[http://de.wikipedia.org/wiki/Betriebssystem-Shell|Terminal bzw. einer Shell]] gemeint. Natürlich gibt's auch [[http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-cee25e252efc24b245482fe9fa8d24ff5d5af1d6|z.T. ganz hübsche GUIs]] (u.a. [[http://gitx.frim.nl/seeit.html|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 [[http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html#_using_git_for_collaboration|"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 [[http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html|Git Tutorial]].
+==Hilfe!
+<code>
+$ git help
+</code>
+==Wer bin ich?
+Damit git weiß mit wem es zu tun hat, sollte man sich gleich nach der Installation einmalig vorstellen:
+<code>
+$ git config --global user.name "Your Name Comes Here"
+$ git config --global user.email you@yourdomain.example.com
+</code>
+==Erstmalig ein fremdes Archiv herunterladen
+<code>
+$ git clone <adresse>
+</code>
+Wobei die Adresse z.B. <nowiki>http://www.meinedomain.de/irgendwas/meinprojekt.git</nowiki> lautet. Auch andere als <nowiki>http://</nowiki> Adressen sind möglich, Details dazu gibt's im Kapitel [[http://www.kernel.org/pub/software/scm/git/docs/git-clone.html#_git_urls_a_id_urls_a|"GIT URLS" der git clone]] Doku.
+Mit <nowiki>.git</nowiki> 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
+<code>
+$ git pull
+</code>
+diese Neuigkeiten in's eigene Archiv herunterzuladen.
+[[http://www.kernel.org/pub/software/scm/git/docs/git-pull.html|git pull Man Page]]
+==Versionen im Archiv angucken
+<code>
+$ gitk --all
+</code>
+Möglicherweise ist auch ein auf git [[http://git.or.cz/gitwiki/InterfacesFrontendsAndTools|aufbauendes Werkzeug]] eine Hilfe. Im Folgenden geht's aber nur um das "originale" git - die Kommandozeilenversion.
+[[http://www.kernel.org/pub/software/scm/git/docs/gitk.html|gitk Man Page]]
+==Änderungen in's eigene Archiv sichern
+Vorher gucken was man selbst alles geändert hat:
+<code>
+$ git status
+</code>
+[[http://www.kernel.org/pub/software/scm/git/docs/git-status.html|git status Man Page]]
+Und ab in's Archiv damit:
+<code>
+$ git commit -a -m "Meine Kurzbeschreibung warum die Version jetzt besser ist als zuvor oder warum ich sie sichern will."
+</code>
+[[http://www.kernel.org/pub/software/scm/git/docs/git-commit.html|git commit Man Page]]
+==Vorhandene Entwicklunglinien (Zweige) auflisten==
+<code>
+$ git branch
+</code>
+wobei der aktuell aktive Zweig farblich hervorgehoben und mit einem * markiert ist.
+[[http://www.kernel.org/pub/software/scm/git/docs/git-branch.html|git branch Man Page]]
+==Eine neue Entwicklunglinie (Zweig) beginnen
+<code>
+$ git branch dasneuethema
+</code>
+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
+<code>
+$ git checkout dasneuethema
+</code>
+schaltet zu einem Zweig ''dasneuethema'' um. Wieder zum Hauptzweig kommt man mit
+<code>
+$ git checkout master
+</code>
+Der Zweig "master" wird ist von Haus aus angelegt und bedeutet die "Hauptentwicklung", bzw. den produktiven, offiziellen Stand des Projekts.
+[[http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html|git checkout Man Page]]
+==Änderungen aus einem Zweig in einen anderen (oder die Hauptrichtung) übernehmen
+Diese Aktion benötigt zwei git Aufrufe:
+<code>
+$ git checkout zweig_wo_solls_hin
+</code>
+Wenn's in die Hauptentwicklung einfließen soll, steht statt ''zweig_wo_solls_hin'' der Zweig ''master''.
+Und danach:
+<code>
+$ git merge zweig_wo_kommts_her
+</code>
+[[http://www.kernel.org/pub/software/scm/git/docs/git-merge.html|git merge Man Page]]
+==Ä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
+<code>
+$ git update-server-info
+</code>
+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 <nowiki>http://...</nowiki> Webadresse zu nennen.
+[[http://www.kernel.org/pub/software/scm/git/docs/git-update-server-info.html|git-update-server-info Man Page]]
+{{tag>Howto SCM Git Versionsverwaltung}}

🐳

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge