Git-Einfuehrung/Git.tex

\documentclass[german,a4paper]{report}

\usepackage[german]{babel}
\usepackage{graphicx}             % Benoetigt, um Grafiken einzubinden
\usepackage{longtable}
\usepackage{float}
\usepackage{german}
\usepackage{ae}

\usepackage[latin1]{inputenc}           % Umlaute und dt. Zeichen Kodieren

% ae.sty verwenden!
\usepackage[T1]{fontenc}                % ec* Schriftarten verwenden

\usepackage{times}                      % Times-Schriftart (pdf)
\usepackage{calc}

\begin{document}

\title{GIT - Eine Einf"uhrung}
\author{Hauke Z"uhl <hzuehl@hauke-zuehl.de>}

\maketitle

\tableofcontents

\chapter{Was ist GIT?}
GIT ist ein sogenanntes ``Versionskontrollsystem'' von Dateien in Projekten, das heisst,
man kann die Ver"anderungen, die an Dateien im Laufe der Zeit durchgef"uhrt werden,
nachvollziehen. Dabei werden nicht nur Zeitstempel gespeichert, sondern auch welcher
Benutzer die "Anderungen durchgef"uhrt hat. Dies ist dann ein Versionsstand eines
Projektes.

GIT speichert also nur Ver"anderungen. Gut, bei sog. ``Bin"ardateien'', also zum Beispiel
LibreOffice-Dokumenten, geht das nicht, aber das ist ein anderes Thema. Immerhin kann
man aber auch LO-Dokumente speichern, wie man an und f"ur sich alles, was eine Datei ist,
in GIT gespeichert werden kann.

Was GIT besonders macht, ist die Tatsache, dass es dezentral ist. Das bedeutet, dass jeder,
der ein Projekt aus GIT herunterl"adt (man sagt auch ``auschecken'' dazu) den kompletten
Versionsverlauf auf seinem Rechner als lokale Kopie verliegen hat.

Im ersten Moment mag das ein Nachteil sein, denn man will ja nicht die Dateiversionen
haben, die Max Mustermann vor 10 Jahren in GIT hochgeladen hat, aber keine Sorge, GIT
arbeitet recht platzsparend.

Der Vorteil dieser Methode ist, dass man dadurch mindestens eine Sicherheitskopie auf
einem Rechner hat.
Arbeiten mehrere Leute an einem Projekt, kommen so diverse Sicherheitskopien zustande.

Diese Einf"uhrung soll mit einfachen Worten und Beispielen an GIT heranf"uhren. Ich
konzentriere mich dabei auf die Konsole, denn nur auf der Konsole kann man meiner Meinung
nach die Arbeitsweise von GIT verinnerlichen. Grafische Clients kann man sp"ater immer
noch einsetzen!

\chapter{Fachbegriffe}
Ohne Fachbegriffe, die "uberwiegend in Englisch sind, kommt man leider bei der Benutzung
und der Erkl"arung von GIT nicht aus, deshalb hier die grundlegenden Fachbegriffe:

``Repository'':

Man kann es als ``Projekt'' bezeichnen. Im Repository (verk"urzt auch nur ``Repo'' genannt)
findet man die Verzeichnnisse und Dateien des Projektes wieder.

``Einchecken'':

Neue Dateien, die zum Repo hinzugef"ugt werden, werden ``eingecheckt'', aber wenn auch
"Anderungen an Dateien dem Repo hinzugef"ugt werden, spricht man von ``einchecken''. Auch
``commit'' genannt.

``Auschecken'' / ``Klonen'':

Unter ``Auschecken'' versteht man umgangssprachlich(!) das Herunterladen eines GIT-Repositories.
Korrekterweise bedeutet ``auschecken'', dass sog. ``Zweige'' auscheckt. Der Begriff des Zweiges
wird sp"ater genauer erl"autert. An dieser Stelle sei nur sovierl dazu gesagt, dass man mit Zweigen
Projekte weiter unterteilen kann.

Wenn man ein Repository klont, dann bezieht sich das auf das GIT-Kommando, um ein Repository
von einem GIT-Server herunterzuladen.

``Branch'':

Ein ``Branch'' ist ein Zweig eines Projektes. Dazu sp"ater mehr.

``Merge'':

Das Zusammenf"uhren zweier Zweige wird als ``merge'' bezeichnet.

\chapter{Erste Schritte mit GIT}

Um mit GIT zu arbeiten, braucht man erst einmal das Programm.\\
Unter Linux kann man sich GIT mit Hilfe des distributionseigenen Installationsprogrammes
installieren. Unter Debian oder Ubuntu zum Beispiel per \textit{aptitude install git}, bzw. per
\textit{apt-get install git}. RedHat oder CentOS liefert GIT per \textit{yum install git}
auf die Platte. Und unter MacOS d"urfte \textit{brew install git} zum Erfolg f"uhren. Mangels
MAC kann ich das nicht pr"ufen.\\
Ein Tip: Vergiss erst einmal grafische Clients, das ist Bl"odsinn, denn damit lernt man nicht
mit GIT umzugehen und zu verstehen! Denk auch nicht an irgendwelche Server oder gar an GitHub!
Wir fangen einfach an und das ist lokal bei dir auf deinem Computer.\\
\\
Los geht's!\\
\\
"Offne eine Konsole deiner Wahl. Bash, zsh, ksh, egal. Irgendwas, wo du mit Hilfe deiner
Tastatur deinem Rechner Kommandos senden kannst\footnote{Manche Shells ben"otigen den
Befehl \textit{rehash}, wenn neue Software hinzugekommen ist}.\\
Es empfiehlt sich, f"ur Git-Repos ein eigenes Verzeichnis anzulegen. Zum Beispiel \textit{git}
oder \textit{projekte}, oder, oder, oder.\\
Ich selbst verwende \textit{git}.\\
\\
Also: \textit{mkdir git}, dann \textit{cd git}.\\
\\
Jetzt legen wir ein Verzeichnis f"ur unser erstes Projekt an. Lass uns das Projekt ``Welt''
nennen: \textit{mkdir Welt}. Per \textit{cd Welt} wechseln wir in das neue Verzeichnis.\\
Jetzt wird es ernst, wir erzeugen unser erstes GIT-Repository: \textit{git init}. Yes!\\
Wenn man nun per \textit{ls -oha} nachguckt, sollte das Verzeichnis so aussehen:
\begin{verbatim}
insgesamt 12K
drwxrwxr-x  3 hauke 4,0K Mar 22 13:03 .
drwxrwxr-x 18 hauke 4,0K Mar 22 13:03 ..
drwxrwxr-x  7 hauke 4,0K Mar 22 13:03 .git
\end{verbatim}
Das Verzeichnis .git ist ein verstecktes Verzeichnis, dort stehen Informationen f"ur GIT in
diversen Dateien.\\
\\
Wir k"onnen nun loslegen, Dateien anzulegen. Fangen wir erst einmal einfach an und legen
eine Datei LIESMICH an. Ich verwende an dieser Stelle den Editor vi, wenn du aber einen
anderen Editor verwenden magst, nutze diesen; es geht nur darum, Text in eine einfache
Datei zu schreiben (Officeprogramme scheiden also aus!).\\
Der Inhalt der Datei soll ganz einfach sein:
\begin{verbatim}
Projekt Welt
\end{verbatim}
Abspeichern nicht vergessen!\\
Jetzt sieht unser Verzeichnis (\textit{ls -oha}) so aus:
\begin{verbatim}
insgesamt 16K
drwxrwxr-x  3 hauke 4,0K Mar 22 13:20 .
drwxrwxr-x 18 hauke 4,0K Mar 22 13:03 ..
drwxrwxr-x  7 hauke 4,0K Mar 22 13:06 .git
-rw-rw-r--  1 hauke   14 Mar 22 13:20 LIESMICH
\end{verbatim}
Jetzt fragen wir mal GIT, was es davon h"alt, dass in dem Repository eine Datei neu
angelegt wurde. Dazu geben wir \textit{git status} ein. Das Ergebnis sollte in etwa so aussehen:
\begin{verbatim}
Auf Branch master

Initialer Commit

Unversionierte Dateien:
  (benutzen Sie "git add <Datei>...", um die Aenderungen
   zum Commit vorzumerken)

        LIESMICH

nichts zum Commit vorgemerkt, aber es gibt unversionierte
Dateien
(benutzen Sie "git add" zum Versionieren)
\end{verbatim}
GIT gibt uns einige Informationen:\\
Wir sind auf dem Branch (Zweig) ``master''. Dazu - wie gesagt - sp"ater mehr.\\
Unser erstes Einchecken (commit) steht bevor; es ist der initiale Commit.\\
Git hat festgestellt, dass es Dateien gibt, "uber die es nichts weiss. Unversionierte
Dateien also. Die Datei(en) wird/werden aufgez"ahlt und es gibt - zumindest bei mir -
einen hilfreichen Tip, was man machen sollte (\textit{git add ...}).\\
Also, ran an den Speck und die Datei per \textit{git add LIESMICH} zum Einchecken vormerken.
Ein \textit{git status} sollte nun folgendes ergeben:
\begin{verbatim}
Auf Branch master

Initialer Commit

zum Commit vorgemerkte Aenderungen:
  (benutzen Sie "git rm --cached <Datei>..." zum
   Entfernen aus der Staging-Area)

        new file:   LIESMICH
\end{verbatim}
Prima, das sieht schon anders, besser aus!\\
Jetzt kann ich nat"urlich weitere Dateien anlegen und per \textit{git add ...} vormerken,
oder ich kann diese eine Datei in das Repository "ubernehmen, den ``commit'' also
durchf"uhren. \textit{git commit LIESMICH} f"uhrt den Commit auf die Datei LIESMICH aus.
Es sollte sich ein Editorfenster "offnen, denn GIT bietet dir jetzt an, in einem
Kommentar kurz zu erl"autern,
was du gemacht hast. Dieser Text taucht dann in der Historie des Projektes sp"ater auf.
Beispiel: ``LIESMICH angelegt''. Kurz und knackig sollte der Kommentar sein, aber auch
so geschrieben, dass du sp"ater noch weisst, was du seinerzeit gemacht hast.\\
GIT gibt dir auch hier wieder eine R"uckmeldung:
\begin{verbatim}
[master (Basis-Commit) 19a30b3] LIESMICH angelegt
 1 file changed, 2 insertions(+)
 create mode 100644 LIESMICH
\end{verbatim}
In der ersten Zeile wird der Branch angezigt, der Commit-Hash (ist auch an dieser Stelle
nicht weiter wichtig, ich erw"ahne es aber dennoch, der "Ubersicht halber) und dein
Kommentar. In der zweite Zeile wird die Anzahl der ver"anderten Dateien, sowie hinzugekommene
Zeilen (insertions) und (hier noch nicht sichtbar) die Anzahl der entfernten Zeilen.
In der dritten Zeile stehen dann noch Information bzgl. des Modus der Datei (create), die
Dateirechte und der Dateiname.\\
Super, damit ist die erste Version des Projektes ``Welt'' im GIT-Repository angekommen.

Am Beispiel einer weiteren Datei zeige ich dir nun auch erste ``Vereinfachungen'', denn mal
angenommen, du hast auf einem Satz mehrere Dutzend Dateien neu in deinem Projekt, dann
wirst du nicht per \textit{git add datei1}, \textit{git add datei2}, usw. jede einzelne
Datei vormerken. Die Sache ginge ja dann so sp"ater beim commit weiter. Also, eher wird
der BER fertig, als dass du mit deinem Projekt weiterkommst!\\
Als Beispiel gibt es jetzt das Shellskript ``welt.sh'':
\begin{verbatim}
#!/bin/sh

echo "Hallo Welt"
\end{verbatim}
Jetzt kommt das ``add'' mal etwas anders: \textit{git add .} Du hast den Punkt hinter ``add''
bemerkt? Gut! Damit hast du jetzt alle neuen Dateien in diesem Verzeichnis (Unterverzeichnisse,
sofern vorhanden mit eingeschlossen) zum einchecken vorgemerkt. \textit{git status} wird
dir das anzeigen.\\
Jetzt das tats"achliche Einchecken in das Repository und da verrate ich dir den n"achsten
Trick: Den Kommentar direkt angeben, ohne dass ein Editor erst "offnet: \textit{git commit -a
-m 'Projekt erweitert, neue Dateien hinzugefuegt'}.\\
Das erkl"are ich mal genauer:\\
-a bedeutet, dass alle (-a = all) Dateien, die vorher per \textit{git add .}, bzw. per
\textit{git add dateiname} vorgemerkt wurden nun in das Repo "ubernommen werden sollen. Du siehst:
Man kann auch erst einmal ``sammeln''.\\
-m bedeutet, dass nun ein Kommentar kommt (-m = message). Der Text sollte in Anf"uhrungszeichen
stehen, sonst macht die Shell "Arger.\\
Und damit hast du bereits die ersten Schritte gemacht.\\
Hier noch mal zusammengefasst die Schritte, die im Wesentlichen immer wieder wiederholt
werden, nachdem man das Projektverzeichnis angelegt und GIT initialisiert hat:
\begin{itemize}
\item Datei anlegen
\item git add
\item git commit
\item Datei anlegen
\item git add
\item git commit
\item ...
\end{itemize}
Oder aber man macht:
\begin{itemize}
\item Datei anlegen
\item Datei anlegen
\item Datei anlegen
\item Datei anlegen
\item Datei anlegen
\item Datei anlegen
\item Datei anlegen
\item Datei anlegen
\item Datei anlegen
\item git add .
\item git commit -a
\item Datei anlegen
\item ...
\end{itemize}

\chapter{GIT konfigurieren}
Oftmals sehen die Logs von GIT ziemlich d"amllich aus, was meistens daran liegt, dass
die Benutzer ihr GIT nicht ordentlich konfiguriert haben. F"ur eine vern"unftige
Konfiguration bedarf es des korrekten Namens und der Mailadresse.\\
Dies geschieht per \textit{git config ...}. Beispiel:
\textit{git config user.name 'Max Mustermann'}, um den Namen festzulegen und
\textit{git config user.email 'mmuster@exampel.kom} f"ur die Mailadresse.\\
Damit sind Name und Mailadresse f"ur dieses eine Projekt festgelegt. Damit das
f"ur alle GIT-Repositories gilt, f"ugt man die Option \textit{--global} hinzu, also
\textit{git config --global user.name 'Max Mustermann'} und
\textit{git config --global user.email 'mmuster@exampel.kom}.\\
Man kann nat"urlich noch eine Menge mehr konfigurieren, aber hier geht es um die Grundlagen.

\chapter{Zweige}
Bisher haben wir uns geradlinig auf dem Zeitstrahl bewegt, aber wenn man im Team an
einem gro"sen Projekt arbeitet, dann erledigt jeder, bzw. jede entsprechende Unteraufgaben.
Um solche Unteraufgaben zu organisieren, nutzt man in Versionskontrollsystemen sog.
``Zweige''. Leider kann man das nicht direkt mit einem Baum vergleichen, denn zwar
gibt es sowohl beim Baum als auch in GIT einen Hauptzweig/Stamm und (mehr oder weniger)
viele Zweige, bei einem Baum werden die Zweige aber nicht wieder zum Stamm zur"uckgef"uhrt.
Bei Versionskontrollsystemen jedoch werden Zweige fr"uher oder sp"ater wieder in den Hauptzweig
"uberf"uhrt.\\
\\
Am Anfang befindet man sich immer auf dem Hauptzweig, dem sog. ``Masterbranch''. Du hast das
bereits in diversen Meldungen von GIT gesehen.\\
Das sieht dann so aus:
\begin{verbatim}
master A--B--C--D--E--F
\end{verbatim}
Um nun einen neuen Zweig zu erzeugen, gibt man
\textit{git checkout -b <Zweigname>}\footnote{-b bedeutet, dass der Zweig erzeugt und sofort
ausgecheckt wird, d.h. man befindet sich sofort auf diesem Zweig} ein.
Angenommen, ich will als Unteraufgabe zum Projekt ``Welt'' ein ``Hallo'' programmieren,
dann erzeuge ich den Zweig ``Hallo'' per \textit{git checkout -b hallo}. Wir sind nun im Zweig
``hallo''. Um das zu "uberpr"ufen gibt es \textit{git branch}:
\begin{verbatim}
* hallo
  master
\end{verbatim}
Der kleine Stern in der ersten Spalte zeigt den Zweig an, in dem wir uns aktuell befinden.\\
Will ich auf den Zwei ``master'' zur"uckwechslen, gebe ich \textit{git checkout master} ein.
Wichtig: Hier wird kein ``-b'' verwendet, da es den Zweig ``master'' bereits gibt!\\
\\
Bist du also im Zweig ``hallo'', gehst du wieder wie immer vor: Datei(en) anlegen, vormerken,
einchecken.\\
Das sieht dann so aus:
\begin{verbatim}
master A--B--C--D--E--F
           \
hallo       G--H--I--J--K
\end{verbatim}
Das sollte soweit klar sein, aber irgendwann kommt der Punkt, an dem du den
Zweig ``hallo'' wieder in den Zweig ``master'' zur"uckf"uhren willst/musst.\\
Dazu wechselst du erst einmal in den Zweig ``master'' zur"uck. Nun sagst du GIT, dass du den
Zweig ``hallo'' in den Masterbranch ``mergen'' willst: \textit{git merge hallo}.
Es "offnet sich wieder ein Editor, indem (meistens) bereits eine Information vorgegeben ist:
\begin{verbatim}
Merge branch 'hallo'
\end{verbatim}
Hinweis: Es muss(!) ein Kommentar angegeben werden, und sei es nur der vorgegebene
Standardkommentar!\\
Wenn alles gutgegangen ist, sind nun alle Dateien des ``hallo''-Zweiges im Masterbranch.\\
Das sieht dann so aus:
\begin{verbatim}
master A--B--C--D--E--F---L
           \             /
hallo       G--H--I--J--K
\end{verbatim}
In der Softwareentwicklung wird generell mit mehreren Zweigen gearbeitet, um zu verhindern,
dass ungetestete und in der Entwicklung befindliche Dateien Einzug in das fertige Projekt
nehmen. Es gibt daher einmal nat"urlich den Zweig ``master'', in dem das fertige Produkt
liegt, dann den Zweig ``develop'', in dem entwickelt wird und von dem weitere Zweige mit
weiteren Unteraufgaben abgeleitet werden. Wenn in ``develop'' alles ordentllich l"auft, dann
wird dieser in den Masterbranch gemergt und das Produkt wird ver"offentlicht.
Dadurch ergibt sich mit der Zeit eine durchaus recht breite Struktur, die aber dem Team
hilft, dass man sich nicht in die Quere kommt und letztendlich auch den "Uberblick
beh"alt.

\chapter{Ein erstes Fazit}
Du solltest nun in der Lage sein, lokal auf deinem Rechner GIT-Repositories anzulegen,
Dateien hinzuzuf"ugen und diese auch in das Repo zu laden. Ausserdem solltest du dir
auch "uber Zweige klar sein und diese verwenden k"onnen, denn mit Hilfe von Zweigen wird
eine koordinierte Teamarbeit in einem Projekt erst m"oglich, aber auch wenn du alleine
an einem Projekt arbeitest, solltest du dir angew"ohnen, f"ur jede Teilaufgabe einen eigenen
Zweig anzulegen.

\chapter{Dateien l"oschen und umbenennen}
Dateien anlegen kannst du jetzt schon fl"ussig, was aber ist, wenn du eine versionierte Datei
nicht mehr brauchst, oder wenn du dich beim Namen vertippt hast?\\
Keine Panik, auch das geht mit GIT.\\
Um eine Datei zu l"oschen, die im GIT-Repository ist, verwendest du den Removebefehl:
\textit{git rm <dateiname>}. Danach f"uhrst du ein \textit{git commit -m 'Kommentar'} aus und die
Datei ist von jetzt an nicht mehr vorhanden.\\
Umbenennen geht ebenfalls sehr einfach: \textit{git mv <alter name> <neuer name>}. Auch danach
wieder ein \textit{git commit -m 'Kommentar'} und die Datei hat von nun an einen neuen
Namen.\\
Moment mal, was soll das heissen ``von nun an''?\\
Ganz einfach: Da man mit GIT auch "altere Versionen des Repositories auschecken kann, hat in
fr"uheren Versionen die Datei nat"urlich noch ihren alten Namen, bzw. ist im Repo noch
vorhanden! Wie man fr"uhere Versionen auscheckt, erkl"are ich aber sehr viel sp"ater.

\chapter{GIT-Server}

\section{Einstieg}
So, jetzt kommt der sog. ``heisse Scheiss''! GIT in Verwendung mit einem GIT-Server!\\
Bisher hast du deine Repositories lokal auf deinem Rechner gehabt und das ist am Anfang
auch gut so, aber stelle dir vor, deine Festplatte zerlegt sich und dein echt tolles
Projekt wird damit geschreddert. Dann n"utzt dir auch GIT nichts mehr. Gut, du h"attest
regelm"a"sig eine Sicherung deines Repos auf DVD, CD, USB-Stick oder wo auch immer anlegen
k"onnenen, aber mal ehrlich, das ist nicht Sinn und Zweck von GIT. Ausserdem funktioniert
so die Teamarbeit an einem Projekt nicht.
Also ben"otigt man externen Speicherplatz. Auf einem GIT-Server.\\
Als Plattform kannst du "offentliche Server nehmen. GitHub sei hier erw"ahnt.\\
Du kannst dir einen GIT-Server auch auf einem kleinen Raspberry Pi in deinem Heimnetzwerk
einrichten. Oder du mietest dir einen eigenen Rootserver und packst dort deinen GIT-Server
drauf. Alles kein Problem!

\section{GitHub}
GitHub ist eine - f"ur nichtkommerzielle Projekte - kostenlose Plattform, die GIT anbietet.
Man kann nat"urlich Geld zahlen, dann bekommt man etwas mehr an ``Features'' auf der Plattform,
aber f"ur den Hausgebrauch reicht die kostenlose Variante.\\
Du meldest dich bei GitHub an und hinterlegst dort deinen "offentlichen
SSH-Schl"ussel\footnote{Wie man SSH-Schl"ussel erstellt, m"ogest du bitte im WWW selbst"andig
suchen}.\\
Du kannst dort deine Projekte komplett verwalten, die Seite ist sehr "ubersichtlich
aufgebaut und es gibt auch eine Hilfefunktion.

\section{GIT-Server im Heimnetzwerk}
F"ur einen GIT-Server im eigenen Heimnetzwerk eignet sich ein Raspberry Pi wunderbar. Der
sollte nat"urlich "uber LAN (und nicht via WLAN) mit dem Netz verbunden sein, damit die
Daten"ubertragung m"oglichst hastig erfolgen kann. Eine FritzBox zum Beispiel hat
Gigabitinterfaces, da kann man schon mal gut was "uber die Leitung jagen (wobei des Raspberries
Interface langsamer ist).\\
Als GIT-Serversoftware empfehle ich an dieser Stelle gogs\footnote{https://gogs.io/}.\\
Wenn du dich damit besch"aftigen willst, solltest du aber "uber gute Linuxkenntnisse
verf"ugen.\\
Mit gogs hast du eine Weboberfl"ache, "ahnlich wie bei GitHub, unter der du deine Projekte
recht einfach verwalten kannst. Du hast auch die M"oglichkeit, private Projekte dort anzulegen.

\section{GIT from scratch}
Ich habe keine bessere "Uberschrift gefunden, aber wenn du keine Lust auf GitHub oder gogs oder
wie auch immer das coole (Web-)Frontend heisst, dann reicht auch...git.\\
Dann legst du als Benutzer ``root'' einen Benutzer ``git'' an. Hast du das erledigt, wirst
du zum Benutzer ``git'' und legst ein Verzeichnis ``.ssh'' im Benutzerverzeichnis von ``git''
an. In das Verzeichnis ``.ssh'' kommen in die Datei ``authorized\_keys'' die "offentlichen
SSH-Schl"ussel der Benutzer, die git benutzen d"urfen.\\
Also:
\begin{verbatim}
sudo adduser git
su git
mkdir .ssh
chmod 700 .ssh
\end{verbatim}
Jetzt kannst du - als Benutzer ``git'' anfangen, Repositories anzulegen:
\begin{verbatim}
mkdir Welt.git
cd Welt.git
git --bare init
\end{verbatim}
Du siehst hier wieder den ``init''-Befehl, diesmal jedoch mit der Option ``--bare''. Diese
Option sorgt daf"ur, dass kein sog. ``Arbeitsverzeichnis'' angelegt wird, d.h. es fehlt das
.git-Verzeichnis, daf"ur sind dort andere Dateien und Verzeichnisse erzeugt werden, die
zur Verwaltung eines GIT-Repositories n"otig sind (guck einfach mal per \textit{ls -oha} nach).
Okay, du hast keine Lust? So sieht das Verzeichnis dann aus:
\begin{verbatim}
drwxrwxr-x  7 git 4,0K Mar 22 18:11 .
drwxrwxr-x 19 git 4,0K Mar 22 18:11 ..
drwxrwxr-x  2 git 4,0K Mar 22 18:11 branches
-rw-rw-r--  1 git   66 Mar 22 18:11 config
-rw-rw-r--  1 git   73 Mar 22 18:11 description
-rw-rw-r--  1 git   23 Mar 22 18:11 HEAD
drwxrwxr-x  2 git 4,0K Mar 22 18:11 hooks
drwxrwxr-x  2 git 4,0K Mar 22 18:11 info
drwxrwxr-x  4 git 4,0K Mar 22 18:11 objects
drwxrwxr-x  4 git 4,0K Mar 22 18:11 refs
\end{verbatim}
Falls du es dir noch nicht gedacht hast: Du kannst das lokal auf deinem Rechner machen! Damit
wird dein Rechner zum GIT-Server! Und was auf deinem Rechner funktioniert, klappt auch auf
einem Raspberry Pi, der in deinem Keller oder auf dem Dachboden rumliegt oder auf dem
dicken Server, der irgendwo in einem Rechenzentrum in Deutschland steht.

\chapter{Projekt ``Welt'' auf den Server bringen}
Nachdem du also einen GIT-Server irgendwie ans Laufen gebracht hast, oder du dich bei GitHub
angemeldet hast, soll das ``Welt''-Projekt nun auf den entfernten Server gebracht werden.

Ob dein GIT-Server nun auf deinem Raspberry oder auf deinem lokalen Server l"auft, der Unterschied
liegt in der Benennung des Rechners. Ich erkl"are dir die folgenden Schritte unter der Annahme,
dass du den GIT-Server auf deinem Rechner installiert hast. Die Transferleistung hin zum
Raspberry Pi oder einem Rootserver "uberlasse ich dir.\\
Um dein Projekt auf den Server hochzuladen, musst du dich im Repoverzeichnis befinden, wo wir uns am
Anfang dieses Papiers aufgehalten haben. Also \textit{cd ~/git/Welt}. Zu Beginn wollen wir
den Masterbranch hochladen, also zur Sicherheit ein \textit{git checkout master} machen.\\
Achtung, jetzt geht es los:\\
\begin{verbatim}
git remote add origin git@localhost:Welt.git
git push origin master
\end{verbatim}
Damit hast du deinen Masterbranch auf den Masterbranch des GIT-Servers geladen, wobei der Server
daf"ur sorgt, dass deine "Anderungen mit dem bereits bestehenden Branch ``gemergt'' werden.
Bei einem krachneuen Branch ist das nat"urlich nicht n"otig, aber sp"ater einmal, wenn du
ein ganzes Team an deinem Projekt mitwerkeln l"asst, dann ist das wichtig.\\
\\
Also, mal die Erkl"arung:\\
Mit der ersten Zeile hast du deinem Repository gesagt, dass unter dem Namen ``origin'' ein
entferntes (remote) Repo existiert. Und zwar beim Benutzer ``git'' auf dem Rechner ``localhost''
im Repository ``Welt.git''.\\
Mit der zweite Zeile hast du dann den aktuellen Branch hochgeladen (push) und zwar zu dem
entfernten Repository ``origin'' in dessen Branch ``master''.\\
Die Bezeichnung ``origin'' f"ur ein entferntes Repository ist Standard. Du h"attest es auch
``Pizza'' oder ``Koeln'' nennen k"onnen, Namen sind Schall und Rauch. Dein ``push'' w"are dann
\textit{git push Pizza master}, bzw. \textit{git push Koeln master}. Es ist nur ein Name f"ur die
Verbindungsdaten zum Server (git@localhost:Welt.git).\\
\\
Jetzt hat sich deine Arbeitsweise etwas erweitert:
\begin{itemize}
\item Datei anlegen
\item Datei anlegen
\item Datei anlegen
\item Datei anlegen
\item Datei anlegen
\item Datei anlegen
\item git add .
\item git commit -a
\item Datei anlegen
\item Datei anlegen
\item Datei anlegen
\item Datei anlegen
\item git add .
\item git commit -a
\item git push origin master
\item ...
\end{itemize}
(Gesetzt den Fall, du bist im Masterbranch)

\chapter{Arbeiten im Team}
Du hast bisher alleine mit GIT gearbeitet, hast aber das Projekt, bzw.
die Projekte mit einem GIT-Server verwaltet.\\
Dann ist der Schritt hin zur Teamarbeit f"ur dich recht leicht, denn
du weisst ja, dass du mit \textit{git push ...} Ver"anderungen
hochl"adst.\\
Da aber deine Kolleginnen und Kollegen auch fleissig waren, solltest
du deren "Anderungen  mindestestens einmal am Tag herunterladen
und deine Arbeitskopie damit aktuell halten.\\
Das gilt besonders f"ur die Zweige, die regelm"a"sigen "Anderungen
unterworfen sind. Dies sind meistens
\begin{itemize}
\item master
\item develop
\item testing
\end{itemize}
Um deine Arbeitskopie zu aktualisieren, wechselst du in den entsprechenden
Zwei (zum Beispiel ``develop'') und f"uhrst dort \textit{git pull} aus.\\
Damit werden die "Anderungen vom Server heruntergeladen und in deinen Zweig
eingepflegt.\\
\\
Ein Beispiel aus dem realen Leben:\\
Wenn man in einer Software einen Fehler findet, wird erst einmal ein
Bericht geschrieben und dieser Bericht bekommt eine sog. ``Ticketnummer''.
Zum Beispiel 4711.\\
Du sollst nun Ticket 4711 bearbeiten. Es wird immer (meistens) aus dem
Zweig ``develop'' ein neuer Zweig erstellt. Das heisst, du wechselst
per \textit{git checkout develop} in den Entwicklungszweig und
f"uhrst hier \textit{git pull} aus. Damit ist dein Zweig aktuell und
du kannst mit \textit{git checkout -b bug-4711} den Zweig erzeugen,
um den Fehler zu beheben.\\
Bist du irgendwann fertig damit (und hast immer wieder \textit{git
pull origin bug-4711} gemacht, kannst du deinen Zweig wieder in
den Developbranch ``zur"uckmergen'', bzw ``zur"uckmergen'' lassen.
``Lassen'' deshalb, weil in der Regel ein anderer Programmierer
erst deinen Code testet und f"ur den Merge freigibt, aber das ist
abh"angig von den Regeln der jeweiligen IT-Abteilung.

\chapter{"Altere Version auschecken}
Es wird selten gebraucht, aber manchmal denkt man: ``Verdammt,
an dem Punkt da vor ein paar Tagen/Wochen/Monaten, da lief
das System besser!''\\
Besonders, wenn man mal ``was ausprobieren'' will, ist es
ganz nett, wenn man eine ``uralte'' Version des Projektes
auschecken kann.\\
Geht recht einfach!\\
Na gut, man muss ein wenig arbeiten, denn zuerst muss man
den richtigen Commit wiederfinden. Um das Log eines GIT-Projektes
anzuzeigen, verwendet man \textit{git log}.\\
Das sieht zum Beispiel so aus:
\begin{verbatim}
commit 43632ef9d9ed259a33d030d2e71549bba752e97b
Author: Max Mustermann <hzuehl@phone-talk.net>
Date:   Tue Mar 27 18:10:22 2018 +0200

    blah => blubb

commit 90845d50545e2bb7069622dbe0c645241f25e9d2
Merge: 19a30b3 201d71f
Author: Max Mustermann <hzuehl@phone-talk.net>
Date:   Thu Mar 22 15:08:02 2018 +0100

    Merge branch 'hallo'

commit 201d71f352307d88b98aa4d1c5d5892b468948e7
Author: Max Mustermann <hzuehl@phone-talk.net>
Date:   Thu Mar 22 15:07:54 2018 +0100

    Blah

commit 19a30b330ab250a6d3ab3f0a9ecf1c6d9b2d9fd5
Author: Hauke Z<EFBFBD>hl <hzuehl@phone-talk.net>
Date:   Thu Mar 22 13:40:59 2018 +0100

    LIESMICH angelegt
\end{verbatim}
Zur Info: Ich bin zur Zeit im Masterbranch.\\
\begin{verbatim}
-rw-rw-r-- 1 hauke  0 Mar 22 15:08 blubb
-rw-rw-r-- 1 hauke 14 Mar 22 13:20 LIESMICH
\end{verbatim}
Jetzt will ich die Version vom 22.3, 13:40:59 auschecken.
Das ist der Commit\\
19a30b330ab250a6d3ab3f0a9ecf1c6d9b2d9fd5.
Dann mal los: \textit{git checkout\\
19a30b330ab250a6d3ab3f0a9ecf1c6d9b2d9fd5}\\
Das ist verdammt lang, oder?\\
An dieser Stelle ein Hinweis: Es reichen die eersten 7 Zeichen
des Hashes des Commits, also ein \textit{git checkout 19a30b3}
h"atte es auch getan!\\
Wie dem auch sein, das Verzeichnis sieht jetzt so aus:
\begin{verbatim}
-rw-rw-r-- 1 hauke 14 Mar 22 13:20 LIESMICH
\end{verbatim}
Es fehlt also eine Datei (``blubb'')! Logisch, die gab es zu diesem
Zeitpunkt noch nicht.\\
Aber Vorsicht: Es muss nicht sein, dass du dich dann noch in dem
gew"unschten Zweig befindest; du kannst an jeder Stelle jede
"Anderung auschecken und von da an weitermachen!\\
Tip: Das solltest du ein wenig "uben und noch ein Tip: An
dieser Stelle sind grafische GIT-Clients sehr n"utzlich, um
dir eine gute "Ubersicht "uber dein Projekt zu geben.\\
Wenn du aber tapfer bist und auf der Konsole bleiben willst,
bitte sch"on: \textit{git log --graph} zaubert
ein sch"ones Log auf den Bildschirm. Und wenn du die Kurzform
der Commits haben willst, dann bringt dich
\textit{git log --abbrev-commit --graph} ans Ziel.

\chapter{Zum Ende noch ein paar Ideen und Worte}
Zum Ende hin noch ein paar Anregungen bzgl. der Einsatzzwecke
von GIT.\\
Man kann GIT alleine nutzen, kein Problem. Das f"angt mit den
eigenen Skripten und Programmen an, geht "uber Korrespondenz
bis hin zu Konfigurationsdateien des Rechners (bzw. der Rechner).
Nimm dir zum Beispiel einen Raspberry Pi als GIT- und Puppetserver,
dann kannst du deine Linuxb"uchsen ganz einfach per Puppet
konfigurieren.\\
Oder du willst dir nicht gleich einen Cloudserver einrichten, dann
kannst du deine pers"onlichen Dateien mit Hilfe von GIT verwalten.\\
\\
Ich hoffe, ich konnte dir einen kleinen Einblick in die Arbeitsweise
von GIT vermitteln. Es ist ein wenig "Ubung n"otig, aber mit der Zeit
hast du die Grundkommandos verinnerlicht und solltest keine Probleme
mehr haben.\\
Tip: Committe oft! Damit ist nicht nur das ``commit'' gemeint, sondern
durchaus auch das ``push''. ``push'' sollte aber definitiv immer kurz
vor Feierabend gemacht werden.\\
Mit dieser Einstellung sorgst du daf"ur, dass man deine "Anderungen
bessser nachvollziehen kann; es ist einfacher, zwei oder drei Zeilen
sp"ater nachzuvollziehen, als wenn du 234 Zeilen in 20 Dateien
"anderst und man diese "Anderungen sp"ater nachvollziehen will.
\\
Viel Spa"s mit GIT.

\end{document}