diff --git a/Git.tex b/Git.tex new file mode 100644 index 0000000..8a0525a --- /dev/null +++ b/Git.tex @@ -0,0 +1,622 @@ +\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 } + +\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 ...", 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 ..." 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 }\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 }. 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 }. 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 +Date: Tue Mar 27 18:10:22 2018 +0200 + + blah => blubb + +commit 90845d50545e2bb7069622dbe0c645241f25e9d2 +Merge: 19a30b3 201d71f +Author: Max Mustermann +Date: Thu Mar 22 15:08:02 2018 +0100 + + Merge branch 'hallo' + +commit 201d71f352307d88b98aa4d1c5d5892b468948e7 +Author: Max Mustermann +Date: Thu Mar 22 15:07:54 2018 +0100 + + Blah + +commit 19a30b330ab250a6d3ab3f0a9ecf1c6d9b2d9fd5 +Author: Hauke Zühl +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}