git-labor/Vorlesung/Wissenschaftlich Arbeiten Git.tex

% Dokumentenklasse beamer für Präsentationen
\documentclass[12pt]{beamer}

% Dokumentenklasse handout für Handouts aus beamer
%\documentclass[handout, 11pt]{beamer}

% Theme der Präsentationen
\usetheme[hideothersubsections]{Hannover}
\setbeamertemplate{footline}[text line]
{
\parbox{\linewidth}{\vspace*{-8pt}\hfill\insertpagenumber}
}

\usepackage{pgfpages}
%\pgfpagesuselayout{4 on 1}[a4paper,border shrink=5mm] % For Handout


\usepackage[utf8]{inputenc}
\usepackage[german]{babel}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage{graphicx}
\usepackage{caption}
\usepackage{array}
\usepackage{xcolor}
\usepackage{listings}
\usepackage{lstautogobble}
\definecolor{mygray}{gray}{0.9}

\lstset{
backgroundcolor=\color{mygray},
basicstyle=\scriptsize\ttfamily,
showstringspaces=false,
commentstyle=\color{red},
keywordstyle=\color{blue},
frame=none, % none removes frame around the code
breaklines=true,
autogobble=true,
showtabs=false,
keepspaces=false,
showtabs=false
}

% csquotes erlaubt es Anführungszeichen mit \enquote{text} zu erstellen.
\usepackage[autostyle=true,german=quotes]{csquotes}

% multicol erlaubt die mehrspaltige Darstellungen mit \begin{multicols}
\usepackage{multicol}
%\setbeameroptions{show notes}
%\setbeameroptions{show notes on second screen}


\usepackage{lmodern}
% Das Paket lmodern erspart die folgenden Warnungen:
% LaTeX Font Warning: Font shape `OT1/cmss/m/n' in size <4> not available
% (Font)              size <5> substituted on input line 22.
% LaTeX Font Warning: Size substitutions with differences
% (Font)              up to 1.0pt have occurred.
\usepackage{fontawesome}

% Präsentationsmetadaten
\author{Stefan Möller}
%\institut{DHBW Stuttgart Campus Horb}
\title{Wissenschaftlich Arbeiten: Git}
%\subtitle{}
%\logo{}
%\institute{}
%\date{\today}
%\subject{}
%\setbeamercovered{transparent}

% Dadurch wird verhindert, dass die Navigationsleiste angezeigt wird.
\setbeamertemplate{navigation symbols}{}

% Erstellt am Anfang jeder \section{title} einen Frame mit 
% mehrspaltigem Inhaltsverzeichnis.
\AtBeginSection[]
{
\frame[allowframebreaks]
{
\frametitle{Inhalt}
\tableofcontents[sectionstyle=show/hide,subsectionstyle=show/show/hide]
%\begin{multicols}{2}
%\tableofcontents[currentsection,hideothersubsections]
%\end{multicols}
}
}

\begin{document}

\begingroup
\makeatletter
\setlength{\hoffset}{-.5\beamer@sidebarwidth}
\makeatother
\begin{frame}[plain]
\titlepage
\end{frame}
\endgroup

\section{Einleitung}
\subsection{Vorstellung}
\begin{frame}{Einleitung}{Vorstellung}
\begin{itemize}
\item Stefan Möller
\item 2010 - 2013 DHBW Studium ET Automatisierung bei Eisenmann
\item 2013 Übernahme durch Eisenmann
\item 2014 - 2016 SPS Software Entwicklung Logimover
\begin{figure}
\centering
\includegraphics[width=0.4\linewidth]{images/logimover}
\end{figure}
\end{itemize}
\end{frame}

\begin{frame}{Einleitung}{Vorstellung}
\begin{itemize}
\item 2016 - 2018 C\# Entwicklung und Projektleitung Electrical Engineering Framework
\item 2019 - 2020 C\# Entwicklung und Projektleitung Application Engineering Suite
\item Seit Oktober 2020 bei MANZ AG als Software-Ingenieur (C\#, C++, TwinCat, Angular)
\item E-Mail: stefan@redferne.de
\end{itemize}
\end{frame}


\subsection{Motivation}
\begin{frame}{Einleitung}{Motivation}
Ohne Version Control System [VCS]
\begin{itemize}
\item[\faFolder] Some Project
\item[\faFolder] Some Project alt
\item[\faFolder] Some Project neu
\item[\faFolder] Some Project neuer
\end{itemize}
\end{frame}

\begin{frame}{Einleitung}{Motivation}
Ohne Version Control System [VCS]
\begin{itemize}
\item[\faFolder] Some Project V1
\item[\faFolder] Some Project V2
\item[\faFolder] Some Project V3
\end{itemize}
\end{frame}

\begin{frame}{Einleitung}{Motivation}
Typische Probleme und Fragen
\begin{itemize}
\item Versionsmanagement
\begin{itemize}
\item Wo ist die aktuelle Version?
\item Was ist die zuletzt lauffähige Version?
\item Wo ist Implementierungsversion vom 20.01.2018?
\item Welche Dokumente beziehen sich auf diese Version?
\item Welche Version wurde einem bestimmten Kunden präsentiert?
\end{itemize}
\end{itemize}	
\end{frame}

\begin{frame}{Einleitung}{Motivation}	
\begin{itemize}		
\item Änderungsmanagement
\begin{itemize}
\item Was hat sich seit letzter Woche geändert?
\item Wer hat diese Änderungen gemacht?
\item Warum wurden diese Änderungen gemacht?
\end{itemize}
\end{itemize}	
\end{frame}

\begin{frame}{Einleitung}{Motivation}
Teamarbeit:
\begin{itemize}
\item Austausch der Dokumente via USB-Stick/Festplatte
\item Austausch der Dokumente via E-Mail
\item Netzwerkfestplatte
\item Konventionen und Regeln werden im Team definiert
\end{itemize}
\end{frame}

\begin{frame}{Einleitung}{Motivation}
Probleme:
\begin{itemize}
\item Konventionen und Regeln werden nicht eingehalten
\item Koordination ist aufwendig und führt zu Verzögerungen
\item Varianten und Konfigurationen werden von Hand verwaltet
\item Versions- und Änderungsfragen nicht bzw. nur schwer beantwortbar
\item Geistige Kapazität wird mit "`Kleinkram"' verschwendet
\end{itemize}	
$\rightarrow$ Konventionen müssen technisch erzwungen werden.
\end{frame}

\begin{frame}{Einleitung}{Motivation}
Lösung:
\begin{itemize}
\item Verwenden eines Versionsverwaltungssystems.
\item Damit werden nahezu alle Probleme gelöst mit geringem Mehraufwand.
\item Neben Versionierung auch Datensicherung.
\end{itemize}
\end{frame}

\section{Versionsverwaltung}

\subsection{Konzept}
\begin{frame}{Versionsverwaltung}{Konzept}
\begin{figure}
\centering
\includegraphics[width=0.9\linewidth]{images/grundkonzept-versionsverwaltung.pdf}
\end{figure}
\end{frame}

\subsection{Was ist Versionsverwaltung?}
\begin{frame}{Versionsverwaltung}{Was ist Versionsverwaltung?}
\begin{itemize}
\item System zur Protokollierung von Änderungen an ein oder mehreren Dateien über die Zeit hinweg.
\item Zugriff auf bestimmte Versionen.
\item Einzelne Dateien oder ein ganzes Projekt in einen früheren Zustand zurückzuversetzen, nachzuvollziehen, wer zuletzt welche Änderungen vorgenommen hat, herausfinden wer eine Änderung ursprünglich vorgenommen hat und vieles weitere.
\end{itemize}
\end{frame}

\begin{frame}{Versionsverwaltung}{Was ist Versionsverwaltung?}
\begin{itemize}
\item Koordinierung des gemeinsamen Zugriffs von mehreren Personen/Entwicklern auf die Dateien.
\item Gleichzeitige Entwicklung mehrerer Entwicklungszweige (engl. Branches) eines Projektes (nicht mit Abspaltungen eines anderen Projektes (engl. Fork) verwechseln).
\end{itemize}
\end{frame}

\subsection{Lokale Versionsverwaltung}
\begin{frame}{Versionsverwaltung}{Lokale Versionsverwaltung}
\begin{figure}
\centering
\includegraphics[width=0.7\linewidth]{images/local.png}
\end{figure}
\end{frame}

\begin{frame}{Versionsverwaltung}{Lokale Versionsverwaltung}	
\begin{itemize}
\item Versionsdatenbank auf dem PC.
\item Auschecken einer bestimmten Version.
\item Nur wenn alleine gearbeitet wird.
\item Bei Hardware-Ausfall ohne Backup verliert man alle Dateien.
\end{itemize}	
\end{frame}

\subsection{Zentrale Versionsverwaltung}
\begin{frame}{Versionsverwaltung}{Zentrale Versionsverwaltung}
\begin{figure}
\centering
\includegraphics[width=0.7\linewidth]{images/centralized.png}
\end{figure}
\end{frame}

\begin{frame}{Versionsverwaltung}{Zentrale Versionsverwaltung}	
\begin{itemize}
\item Lokale Versionsverwaltung ist nur so lange möglich, wie alleine an einem Projekt gearbeitet wird.
\item Damit eine Zusammenarbeit möglich ist, wurden Zentrale Versionsverwaltungen entwickelt.
\item Beispiele: CVS, Subversion und Perforce.
\end{itemize}	
\end{frame}

\begin{frame}{Versionsverwaltung}{Zentrale Versionsverwaltung}	
\begin{itemize}		
\item Sie basieren auf einem zentralen Server, der alle versionierten Dateien verwaltet. Die Clients können die Dateien von diesem zentralen Ort abholen und auf ihren PC übertragen. Diesen Vorgang nennt man Ausschecken (engl. to check out).
\end{itemize}	
\end{frame}

\begin{frame}{Versionsverwaltung}{Zentrale Versionsverwaltung}	
\begin{itemize}
\item Dieser Ansatz hat viele Vorteile, besonders gegenüber lokalen Versionsverwaltungssystemen.
\item Jeder weiß mehr oder weniger genau darüber Bescheid, was andere, an einem Projekt Beteiligte gerade tun.
\item Administratoren haben die Möglichkeit, detailliert festzulegen, wer was tun kann.
\item Sehr viel einfacher zu administrieren als lokale Datenbanken auf jedem einzelnen Anwendungsrechner.
\end{itemize}	
\end{frame}

\begin{frame}{Versionsverwaltung}{Zentrale Versionsverwaltung}	
\begin{itemize}
\item Allerdings hat dieser Aufbau auch einige erhebliche Nachteile.
\item Risiko eines Systemausfalls, bei Ausfall einer einzelnen Komponente, nämlich dann wenn der zentralisierte Server ausfällt.
\item Wenn dieser Server ausfällt, dann kann in dieser Zeit niemand in irgendeiner Form zusammenarbeiten oder Dateien, an denen gerade gearbeitet wird, versioniert abspeichern.
\end{itemize}	
\end{frame}

\begin{frame}{Versionsverwaltung}{Zentrale Versionsverwaltung}	
\begin{itemize}
\item Bei Hardware-Ausfall ohne Backup verliert man alle Dateien. Abgesehen natürlich von dem jeweiligen Zustand, den Mitarbeiter gerade zufällig auf ihren Rechnern noch vorliegen haben.
\item Offline Arbeiten ohne den Server ist nicht möglich.
\end{itemize}	
\end{frame}

\subsection{Verteilte Versionsverwaltung}
\begin{frame}{Versionsverwaltung}{Verteilte Versionsverwaltung}
\begin{figure}
\centering
\includegraphics[width=0.65\linewidth]{images/distributed.png}
\end{figure}
\end{frame}

\begin{frame}{Versionsverwaltung}{Verteilte Versionsverwaltung}
\begin{itemize}
\item Beispiele: Git, Mercurial, Bazaar oder Dracs
\item Anwender haben nicht nur den letzten Stand des Servers.
\item Vollständige Kopie des Repositories.
\item Wird der Server beschädigt, kann jedes beliebige Repository von jedem beliebigen Anwenderrechner zurück kopiert werden um den Server wiederherzustellen.
\item Jede Kopie (engl. Clone), ist ein vollständiges Backup der gesamten Projektdaten.
\end{itemize}
\end{frame}

\begin{frame}{Versionsverwaltung}{Verteilte Versionsverwaltung}
\begin{itemize}
\item Man kann auch offline Dateien versionieren.
\item Dezentrale Systeme können hervorragend mit verschiedenen externen Repositories, sogenannten Remote-Repositories, umgehen.
\item So kann eine Gruppe von Leuten simultan an einem Projekt zusammenarbeiten.
\item Es ist möglich zwischen allen Repositories Daten auszutauschen.
\end{itemize}
\end{frame}

\section{Git}
\subsection{Grundlagen}
\begin{frame}{Git}{Geschichte von Git}
Der Linux Kernel ist ein Open Source Software Projekt von erheblichem Umfang. Während der gesamten Entwicklungszeit von 1991 bis 2002 wurden Änderungen an diesem, in Form von Patches und archivierten Dateien herumgereicht. 2002 begann man dann ein proprietäres DVCS mit dem Namen Bitkeeper zu verwenden.\\

2005 wurde die Lizenz von Bitkeeper zur kostenlosen Verwendung bei Open Source Projekten zurückgezogen.


\end{frame}
\begin{frame}{Git}{Geschichte von Git}
Linus Torvalds hat Git aus der Not heraus 2005 in wenigen Tagen geschrieben. Seitdem ist ein großer Teil der freien Software-Projekte auf Git umgeschwenkt. Torvalds hatte Git in rund zehn Tagen entwickelt, um die Quellcode-Verwaltung des Linux-Kernels zu übernehmen.
\end{frame}


\begin{frame}{Git}{Geschichte von Git}	
\begin{itemize}
\item 1991 - 2002 Linux Kernel ohne Versionskontrolle entwickelt.
\item 2002 - 2005 Versionskontrolle mit BitKeeper (proprietäre Software, erlaubte aber freien Projekten eine kostenlose Nutzung).
\item 2005 wurde die freie Lizenz zurückgezogen, nachdem Samba-Entwickler Andrew Tridgell begonnen hatte, angeblich per Reverse Engineering, BitKeeper nachzubilden. Daraufhin schrieb Torvalds nach einer längeren Planungsphase in rund zehn Tagen das heute weit verbreitete VCS Git.
\end{itemize}
\end{frame}

\begin{frame}{Git}{Geschichte von Git}
Ziel des neuen Systems waren unter anderem:
\begin{itemize}
\item Geschwindigkeit
\item Einfaches-Design
\item Gute Unterstützung von nicht-linearer Entwicklung (tausende parallele Entwicklungszweige)
\item Vollständig dezentrale Struktur
\item Fähigkeit große Projekte, wie den Linux Kernel, effektiv zu verwalten (Geschwindigkeit und Datenumfang)
\item Sehr hohe Sicherheit gegen sowohl unbeabsichtigte als auch böswillige Verfälschungen
\end{itemize}
\end{frame}

\begin{frame}{Git}{Geschichte von Git}
Torvalds entwickelte Git mit Hilfe von Git. Lediglich der erste Entwicklungstag fehlt, da es noch kein Git gab. Am zweiten Tag sind die ersten Commits bereits in einem funktionierenden Git-Repository.


\end{frame}
\begin{frame}{Git}{Geschichte von Git}
Der Name Git bedeutet im englischen Blödmann. Torvalds fand den Namen kurz, knackig und bisher in der Softwarewelt unbenutzt. Torvalds eigene selbstironische Erläuterung des Namens lautet:
\\[12pt]
"`Ich bin ein egoistischer Bastard, ich benenne alle meine Entwicklungen nach mir selbst. Erst Linux und nun Git."'
\end{frame}

\begin{frame}{Git}{Grundlagen - Snapshots statt Unterschiede}
\begin{itemize}
\item Hauptunterschied zwischen Git und anderen Versionsverwaltungssystemen besteht in der Art und Weise wie Git die Daten betrachtet.
\item Konzeptionell speichern die meisten anderen Systeme Informationen als eine Liste von dateibasierten Änderungen.
\item Diese Systeme (CVS, Subversion, Perforce, Bazaar usw.) betrachten die Informationen die sie verwalten, als eine Reihe von Dateien an denen im Laufe der Zeit Änderungen vorgenommen werden. (deltabasierte Versionskontrolle).
\end{itemize}
\end{frame}

\begin{frame}{Git}{Grundlagen - Snapshots statt Unterschiede}
\begin{figure}
\centering
\includegraphics[width=1.0\linewidth]{images/deltas.png}
\caption{Speichern von Daten als Änderung an einzelnen Dateien auf Basis einer Ursprungsdatei.}
\end{figure}
\end{frame}

\begin{frame}{Git}{Grundlagen - Snapshots statt Unterschiede}	
\begin{itemize}
\item Git arbeitet nicht auf diese Weise.
\item Git betrachtet Daten eher wie eine Reihe von Schnappschüssen eines Mini-Dateisystems.
\item Git macht bei jedem Commit (Speicherung des gegenwärtigen Status eines Projektes, als eine Version) ein Abbild aller Dateien wie diese gerade aussehen und speichert einen Verweis in diesem Schnappschuss.
\end{itemize}
\end{frame}

\begin{frame}{Git}{Grundlagen - Snapshots statt Unterschiede}
\begin{itemize}		
\item Git betrachtet seine Daten eher wie einen Stapel von Schnappschüssen.
\end{itemize}
\end{frame}

\begin{frame}{Git}{Grundlagen - Snapshots statt Unterschiede}
\begin{figure}
\centering
\includegraphics[width=1.0\linewidth]{images/snapshots.png}
\caption{Speichern der Daten-Historie eines Projekts in Form von Schnappschüssen.}
\end{figure}
\end{frame}

\begin{frame}{Git}{Grundlagen - Snapshots statt Unterschiede}	
\begin{itemize}
\item Git arbeitet im Großen und Ganzen wie ein mit einigen unglaublich mächtigen Werkzeugen ausgerüstetes Mini-Dateisystem, statt nur als Versionsverwaltungssystem.
\item Auf einige Vorteile, die es mit sich bringt, Dateien in dieser Weise zu verwalten, werden wir beim Branching eingehen.
\end{itemize}
\end{frame}

\begin{frame}{Git}{Grundlagen - Fast jede Funktion arbeitet lokal}
\begin{itemize}
\item Die meisten Aktionen in Git benötigen nur lokale Dateien und Ressourcen, um ausgeführt zu werden.
\item Es werden im Allgemeinen keine Informationen von einem anderen Computer im Netzwerk benötigt.
\item Die allermeisten Operationen können nahezu ohne jede Verzögerung ausgeführt werden, da die vollständige History eines Projektes bereits auf dem jeweiligen Rechner verfügbar ist.
\end{itemize}
\end{frame}

\begin{frame}{Git}{Grundlagen - Fast jede Funktion arbeitet lokal}
\begin{itemize}
\item Um beispielsweise die History des Projektes zu durchsuchen, braucht Git sie nicht von einem externen Server zu holen - es liest diese einfach aus der lokalen Datenbank.
\item Ist man also offline und hat keinen Zugriff auf einen Server, kann man mit Git weiterhin seine Arbeit einchecken und wenn man wieder mit dem Server verbunden ist, die Dateien auf den Server hochladen.
\end{itemize}
\end{frame}

\begin{frame}{Git}{Grundlagen - Integrität}
\begin{itemize}
\item Von allen zu speichernden Daten berechnet Git Prüfsummen (engl. checksum) und speichert diese als Referenz zusammen mit den Daten ab.
\item Das macht es unmöglich, dass sich Inhalte von Dateien oder Verzeichnissen ändern, ohne dass Git das mitbekommt.
\item Git basiert auf dieser Funktionalität und sie ist integraler Teil der Git Philosophie.
\end{itemize}
\end{frame}

\begin{frame}{Git}{Grundlagen - Integrität}	
\begin{itemize}
\item Damit kann es nicht passieren, dass Informationen während der Übermittlung verloren werden oder unwissentlich beschädigte Dateien verwendet werden, ohne das Git in der Lage wäre, dies festzustellen.
\item Git verwendet für die Prüfsummen SHA-1 Hash.
\item Eine solche Prüfsumme ist eine 40 Zeichen lange Zeichenkette, die aus hexadezimalen Zeichen (0-9 und a-f) besteht und wird von Git aus den Inhalten einer Datei oder Verzeichnisstruktur berechnet.
\item Ein SHA-1 Hash sieht wie folgt aus: 24b9da6552252987aa493b52f8696cd6d3b00373
\end{itemize}
\end{frame}

\begin{frame}{Git}{Grundlagen - Integrität}	
\begin{itemize}
\item Diese Hashes begegnen einem überall bei der Arbeit, weil sie so ausgiebig von Git genutzt werden.
\item Git speichert alles in seiner Datenbank nicht nach Dateiname sondern nach dem Hash-Wert seines Inhalts.
\end{itemize}
\end{frame}

\begin{frame}{Git}{Grundlagen - Git fügt im Regelfall nur Daten hinzu}	
\begin{itemize}
\item Wenn Aktionen mit Git durchgeführt werden, werden bei fast allen nur Daten zur Git-Datenbank hinzugefügt.
\item Es ist deshalb schwer, das System dazu zu bewegen, irgendwas zu tun, was nicht wieder rückgängig zu machen ist, oder dazu, Daten in irgendeiner Form zu löschen.	
\end{itemize}
\end{frame}

\begin{frame}{Git}{Grundlagen - Git fügt im Regelfall nur Daten hinzu}	
\begin{itemize}		
\item Wie in jedem anderen VCS, kann man in Git Daten verlieren oder durcheinander bringen, solange man sie noch nicht eingecheckt hat. Aber sobald man einen Schnappschuss in Git eingecheckt hat, ist es sehr schwierig, diese Daten wieder zu verlieren, insbesondere wenn man regelmäßig seine lokale Datenbank auf ein anderes Repository hochlädt.
\end{itemize}
\end{frame}

\begin{frame}{Git}{Grundlagen - Git fügt im Regelfall nur Daten hinzu}	
\begin{itemize}
\item Unter anderem deshalb macht es so viel Spaß mit Git zu arbeiten.
\item Man weiß genau, man kann ein wenig experimentieren, ohne befürchten zu müssen, irgendwas zu zerstören oder durcheinander zu bringen.
\end{itemize}
\end{frame}

\begin{frame}{Git}{Grundlagen - Die drei Zustände}	
\begin{itemize}
\item Es folgen die wichtigsten Informationen, die man sich merken muss, wenn man Git erlernen und dabei Fallstricke vermeiden will.
\end{itemize}
\end{frame}

\begin{frame}{Git}{Grundlagen - Die drei Zustände}	
\begin{itemize}
\item Git definiert drei Hauptzustände, in denen sich eine Datei befinden kann: committet (engl. committed), geändert (engl. modified) und für den Commit vorgemerkt (engl. staged).
\begin{description}
\item[Modified] bedeutet, dass eine Datei geändert, aber noch nicht in die lokale Datenbank eingecheckt wurde.
\item[Staged] bedeutet, dass eine geänderte Datei in ihrem gegenwärtigen Zustand für den nächsten Commit vorgemerkt ist.
\item[Committed] bedeutet, dass die Dateien sicher in der lokalen Datenbank gespeichert sind.
\end{description}
\end{itemize}
\end{frame}

\begin{frame}{Git}{Grundlagen - Die drei Zustände}
Das führt uns zu den drei Hauptbereichen eines Git-Projektes: dem Verzeichnisbaum, der sogenannten Staging-Area und dem Git-Verzeichnis.
\begin{figure}
\centering
\includegraphics[width=0.8\linewidth]{images/areas.png}
\caption{Verzeichnisbaum, Staging-Area und Git-Verzeichnis.}
\end{figure}
\end{frame}

\begin{frame}{Git}{Grundlagen - Die drei Zustände}	
\begin{itemize}
\item Der Verzeichnisbaum ist ein einzelner Abschnitt einer Version des Projekts. Diese Dateien werden aus der komprimierten Datenbank im Git-Verzeichnis geholt und auf der Festplatte so abgelegt, damit diese verwendet oder geändert werden können.	
\end{itemize}
\end{frame}

\begin{frame}{Git}{Grundlagen - Die drei Zustände}	
\begin{itemize}	
\item Die Staging-Area ist in der Regel eine Datei, die sich im Git-Verzeichnis befindet und Informationen darüber speichert, was in den nächsten Commit einfließen soll. Der technische Name im Git-Sprachgebrauch ist "`Index"', aber der Ausdruck "`Staging Area"' funktioniert genauso gut.
\end{itemize}
\end{frame}

\begin{frame}{Git}{Grundlagen - Die drei Zustände}	
\begin{itemize}
\item Im Git-Verzeichnis werden die Metadaten und die Objektdatenbank für das Projekt gespeichert. Das ist der wichtigste Teil von Git, dieser Teil wird kopiert, wenn man ein Repository von einem anderen Rechner klont.
\end{itemize}
\end{frame}

\begin{frame}{Git}{Grundlagen - Die drei Zustände}	
Der grundlegende Git-Arbeitsablauf sieht in etwa so aus:
\begin{enumerate}
\item Sie ändern Dateien in Ihrem Verzeichnisbaum.
\item Sie stellen selektiv Änderungen bereit, die Sie bei Ihrem nächsten Commit berücksichtigen möchten, wodurch diese Änderungen in den Staging-Bereich aufgenommen werden.
\item Sie führen einen Commit aus, der die Dateien so übernimmt, wie sie sich in der Staging-Area befinden und diesen Snapshot dauerhaft in Ihrem Git-Verzeichnis speichert.
\end{enumerate}
\end{frame}

\subsection{Voraussetzung}
\begin{frame}{Git}{Git Voraussetzungen}
\begin{itemize}
\item Installation via (https://git-scm.com/)
\item Optional:
\begin{itemize}
\item TortoiseGit (Grafischer Client für Windows)
\item Visual Studio Code (Editor z.B. Commit-Nachrichten, Merges)
\item Posh-Git (PowerShell Erweiterung zur Visualisierung von Git Informationen)
\item Visual Studio enthält Git.
\end{itemize}
\end{itemize}
\end{frame}

\subsection{Konfiguration}
\begin{frame}[fragile]{Git}{Git konfigurieren}
\begin{itemize}
\item Konfiguration anzeigen
\begin{lstlisting}
git config -l
\end{lstlisting}

\item Benutzer einrichten:
\begin{lstlisting}
git config --global user.name "Max Muster"
git config --global user.email "max.must@....com"
\end{lstlisting}

\item Einzelne Konfiguration abfragen:
\begin{lstlisting}
git config user.name
\end{lstlisting}
\end{itemize}
\end{frame}

\begin{frame}[fragile]{Git}{Git konfigurieren}
\begin{itemize}
\item Config wird in verschiedenen Ebenen gespeichert
\begin{lstlisting}
C:/ProgramData/Git/config
C:/Users/$USER
\end{lstlisting}

\item Darüber hinaus pro Repository in
\begin{lstlisting}
.git/config		
\end{lstlisting}

\item Ursprung der Konfiguration anzeigen	
\begin{lstlisting}
git config -l --show-origin
\end{lstlisting}
\end{itemize}
\end{frame}

\subsection{Ein Repository erstellen}
\begin{frame}[fragile]{Git}{Ein Repository erstellen}
\begin{itemize}
\item Repository initialisieren
\begin{lstlisting}
git init
\end{lstlisting}

\item oder 
\begin{lstlisting}
git init my-new-project
\end{lstlisting}
\end{itemize}
\end{frame}

\begin{frame}[fragile]{Git}{Git auf der Kommandozeile nutzen}
\begin{itemize}
\item Den Status abfragen
\begin{lstlisting}
git status
\end{lstlisting}

\item Den Status in Kurzform abfragen
\begin{lstlisting}
git status -s
\end{lstlisting}
\end{itemize}

\begin{itemize}
\item Anzeigen des aktuellen Status.
\item Oft ausführen
\item Immer wissen, was los ist.
\end{itemize}
\end{frame}

\begin{frame}{Git}{Git auf der Kommandozeile nutzen}
Demo: Konfiguration und Repository anlegen
\end{frame}

\subsection{Git auf der Kommandozeile}
\begin{frame}[fragile]{Git}{Git auf der Kommandozeile nutzen}
\begin{itemize}
\item Status Abfragen
\begin{lstlisting}
git status
\end{lstlisting}

\item Datei "`stagen"'
\begin{lstlisting}
git add dateiname.txt oder git add .
\end{lstlisting}

\item Committen 
\begin{lstlisting}
git commit -m "Eine sinnvolle Commit-Nachricht"
\end{lstlisting}

\item oder mit dem eingestellten Git Editor
\begin{lstlisting}
git commit
\end{lstlisting}
\end{itemize}
\end{frame}

\begin{frame}{Git}{Git auf der Kommandozeile nutzen}
Demo: Arbeiten mit Dateien
\end{frame}

\begin{frame}[fragile]{Git}{Git auf der Kommandozeile nutzen}
\begin{itemize}
\item Git Editor Ändern
\begin{lstlisting}
git config --global core.editor notepad
\end{lstlisting}

\item oder für Visual Studio Code
\begin{lstlisting}
git config --global core.editor "code -w"
\end{lstlisting}
\end{itemize}
\end{frame}

\begin{frame}[fragile]{Git}{Git auf der Kommandozeile nutzen}
\begin{itemize}
\item Datei entfernen
\begin{lstlisting}
git rm dateiname.txt
\end{lstlisting}

\item Diff anzeigen
\begin{lstlisting}
git diff
\end{lstlisting}
\begin{lstlisting}
git diff --staged
\end{lstlisting}

\item Diff in Tool anzeigen
\begin{lstlisting}
git difftool
\end{lstlisting}
\begin{lstlisting}
git difftool --tool-help
\end{lstlisting}
\end{itemize}
\end{frame}

\begin{frame}{Git}{Git auf der Kommandozeile nutzen}
Demo: Diff Anzeigen
\end{frame}

\begin{frame}[fragile]{Git}{Log ansehen}
\begin{itemize}
\item Zeige Commits an (mit Snapshot-Hash (SHA1))
\begin{lstlisting}
git log
\end{lstlisting}
\begin{lstlisting}
git log --pretty=oneline
\end{lstlisting}

\item git checkout "`Hashanfang"' checkt den commit aus
\begin{lstlisting}
git checkout fea23ce22
\end{lstlisting}
\end{itemize}	
\end{frame}

\begin{frame}{Git}{Log ansehen}
Demo: Logs ansehen und Commits laden
\end{frame}

\begin{frame}[fragile]{Git}{Dateien ignorieren}
\begin{itemize}
\item .gitignore-Datei anlegen
\item Syntax:
\begin{itemize}
\item Leere und mit \# startende Zeilen werden ignoriert
\item ! Negiert
\item Erlaubt standard Glob Patterns (vergleichbar mit Regex)
\item / am Anfang vermeidet Rekursion
\item / am Ende für Verzeichnisse
\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}[fragile]{Git}{Dateien ignorieren}
Glob Patterns
\begin{itemize}
\item * - keines, eins oder mehrere Zeichen
\item ? - genau ein Zeichen
\item $ [abc] $ - einen Buchstaben in den Klammern
\item $ [0-9] $ - ein Zeichen in der Reihe
\item ** - um verschachtelte Verzeichnisse zu erhalten:\\
a/**/x findet a/x, a/b/x, a/b/c/x usw.
\end{itemize}
\end{frame}

\begin{frame}[fragile]{Git}{Dateien ignorieren}
Beispiel .gitignore Datei:
\begin{lstlisting}
# Ignorieren aller pdf Dateien
*.pdf

# Ignorieren aller pdf Dateien im root Ordner
/*.pdf

# Einzelne Datei zulassen
!Vorlesung.pdf

# Alle Dateien in bin Verzeichnissen ignorieren
**/bin/
\end{lstlisting}
\end{frame}

\begin{frame}[fragile]{Git}{Branches}
\begin{itemize}
\item Branches anzeigen (Aktueller wird mit * gekennzeichnet)
\begin{lstlisting}
git branch
\end{lstlisting}

\item Branch erstellen und ins Arbeitsverzeichnis auschecken
\begin{lstlisting}
git branch myNewBranch
git checkout myNewBranch
\end{lstlisting}

\item Zu anderem Branch wechseln
\begin{lstlisting}
git checkout master
\end{lstlisting}
\end{itemize}
\end{frame}

\begin{frame}[fragile]{Git}{Branches}
\begin{itemize}
\item Branches mergen (in den aktuellen Branch)
\begin{lstlisting}
git merge myNewBranch
\end{lstlisting}

\item Neben Merging gibt es auch Rebasing, hierbei werden Commits auf den Branch übertragen. Rebase darf nicht auf remote-branches angewendet werden.

\item Merge Graph in der Konsole anschauen
\begin{lstlisting}
git log --pretty=oneline --graph
\end{lstlisting}
\end{itemize}

\end{frame}

\begin{frame}{Git}{Branches}
Demo: Arbeiten mit Branches
\end{frame}

\begin{frame}[fragile]{Git}{Tags}
\begin{itemize}
\item Tags anzeigen
\begin{lstlisting}
git tag
\end{lstlisting}

\item Tag erstellen
\begin{lstlisting}
git tag -a 1.0 -m "Release V1.0"
\end{lstlisting}

\item Tag auschecken
\begin{lstlisting}
git checkout 1.0
\end{lstlisting}
\end{itemize}
\end{frame}

\begin{frame}{Git}{Branches}
Demo: Tags benutzen
\end{frame}

\begin{frame}[fragile]{Git}{Remotes}
\begin{itemize}
\item Remotes abfragen
\begin{lstlisting}
git remote
\end{lstlisting}

\item Remotes anlegen
\begin{lstlisting}
git remote add [name] [url]
\end{lstlisting}
\end{itemize}
\end{frame}

\begin{frame}[fragile]{Git}{Remotes}
\begin{itemize}
\item Branch in Remote pushen
\begin{lstlisting}
git push [remote-name] [branch-name]
git push origin master
\end{lstlisting}

\item Upstream setzen
\begin{lstlisting}
git push -u origin master
\end{lstlisting}
ab dann nur noch
\begin{lstlisting}
git push
\end{lstlisting}
\end{itemize}
\end{frame}

\begin{frame}[fragile]{Git}{Remotes}
\begin{itemize}
\item Initialer Klon von Remote
\begin{lstlisting}
git clone [remote-url]
\end{lstlisting}
Damit wird der Remote automatisch unter dem Namen "`origin"' hinzugefügt.

\item Remote Daten laden und mergen
\begin{lstlisting}
git pull origin master
\end{lstlisting}

\item Wenn Upstream gesetzt ist einfach mit 
\begin{lstlisting}
git pull
\end{lstlisting}
\end{itemize}
\end{frame}

\begin{frame}[fragile]{Git}{Remotes}
\begin{itemize}
\item Git pull merged den Remote Branch in den lokalen
\begin{lstlisting}
git pull
\end{lstlisting}

\item Dies ist auch in zwei Schritten möglich
\begin{lstlisting}
git fetch
git merge
\end{lstlisting}

\item Alle Branches anzeigen
\begin{lstlisting}
git branch -a
\end{lstlisting}
\end{itemize}	
\end{frame}

\begin{frame}{Git}{Branches}
Demo: Github
\end{frame}

\begin{frame}[fragile]{Git}{Pull-Request}
Anfrage, den eigenen Branch in den Hauptbranch zu mergen. Administratives Hilfsmittel zur Qualitätskontrolle und Sicherheit vor unbefugten Änderungen.
\end{frame}

\begin{frame}{Git}{Branches}
Demo: Pull-Request durchführen
\end{frame}


% Fehlend:
% Aliase
% Rebase vs Merging
% Git Workflows
% Git Flow
% Trunk-Based Development
% Version Branch instead of Tagging
% Optional: Dateien Verwalten (PARA)




\section{Anhang}
\subsection{Glossar}
\begin{frame}{Glossar}
\begin{itemize}
\item Repository: (Behälter, Aufbewahrungsort) Enthält alle zusammen versionierten Dokumente.
\item Branch (deutsch: Zweig): Verzweigung von einer anderen Version, so dass unterschiedliche Versionen bzw. Funktionen parallel im selben Projekt weiterentwickelt werden können.
\item Merging (deutsch: Verschmelzen): Änderungen eines Branches in einen anderen verschmelzen.
\item Trunk (Subversion) oder Master (Git): Hauptentwicklungszweig
\item Tag: Commit mit einem frei wählbaren Bezeichner (z.B. Versionskennzeichnung)
\end{itemize}
\end{frame}

\begin{frame}[allowframebreaks]{Glossar}

Common terminology

Terminology can vary from system to system, but some terms in common usage include:[6]

Baseline 
An approved revision of a document or source file from which subsequent changes can be made. See baselines, labels and tags.
Branch 
A set of files under version control may be branched or forked at a point in time so that, from that time forward, two copies of those files may develop at different speeds or in different ways independently of each other.
Change 
A change (or diff, or delta) represents a specific modification to a document under version control. The granularity of the modification considered a change varies between version control systems.
Change list 

On many version control systems with atomic multi-change commits, a change list (or CL), change set, update, or patch identifies the set of changes made in a single commit. This can also represent a sequential view of the source code, allowing the examination of source "as of" any particular changelist ID.
Checkout
To check out (or co) is to create a local working copy from the repository. A user may specify a specific revision or obtain the latest. The term 'checkout' can also be used as a noun to describe the working copy. When a file has been checked out from a shared file server, it cannot be edited by other users. Think of it like a hotel, when you check out, you no longer have access to its amenities.
Clone 
Cloning means creating a repository containing the revisions from another repository. This is equivalent to pushing or pulling into an empty (newly initialized) repository. As a noun, two repositories can be said to be clones if they are kept synchronized, and contain the same revisions.
Commit 
To commit (check in, ci or, more rarely, install, submit or record) is to write or merge the changes made in the working copy back to the repository. The terms 'commit' and 'checkin' can also be used as nouns to describe the new revision that is created as a result of committing.
Conflict 
A conflict occurs when different parties make changes to the same document, and the system is unable to reconcile the changes. A user must resolve the conflict by combining the changes, or by selecting one change in favour of the other.
Delta compression 
Most revision control software uses delta compression, which retains only the differences between successive versions of files. This allows for more efficient storage of many different versions of files.
Dynamic stream 
A stream in which some or all file versions are mirrors of the parent stream's versions.
Export 
exporting is the act of obtaining the files from the repository. It is similar to checking out except that it creates a clean directory tree without the version-control metadata used in a working copy. This is often used prior to publishing the contents, for example.
Fetch 
See pull.
Forward integration 
The process of merging changes made in the main trunk into a development (feature or team) branch.
Head
Also sometimes called tip, this refers to the most recent commit, either to the trunk or to a branch. The trunk and each branch have their own head, though HEAD is sometimes loosely used to refer to the trunk.[7]
Import 
importing is the act of copying a local directory tree (that is not currently a working copy) into the repository for the first time.
Initialize 
to create a new, empty repository.
Interleaved deltas 
some revision control software uses Interleaved deltas, a method that allows storing the history of text based files in a more efficient way than by using Delta compression.
Label 
See tag.
Mainline 
Similar to trunk, but there can be a mainline for each branch.
Merge 
A merge or integration is an operation in which two sets of changes are applied to a file or set of files. Some sample scenarios are as follows:

A user, working on a set of files, updates or syncs their working copy with changes made, and checked into the repository, by other users.[8]
A user tries to check in files that have been updated by others since the files were checked out, and the revision control software automatically merges the files (typically, after prompting the user if it should proceed with the automatic merge, and in some cases only doing so if the merge can be clearly and reasonably resolved).
A branch is created, the code in the files is independently edited, and the updated branch is later incorporated into a single, unified trunk.
A set of files is branched, a problem that existed before the branching is fixed in one branch, and the fix is then merged into the other branch. (This type of selective merge is sometimes known as a cherry pick to distinguish it from the complete merge in the previous case.)

Promote 
The act of copying file content from a less controlled location into a more controlled location. For example, from a user's workspace into a repository, or from a stream to its parent.[9]
Pull, push
Copy revisions from one repository into another. Pull is initiated by the receiving repository, while push is initiated by the source. Fetch is sometimes used as a synonym for pull, or to mean a pull followed by an update.
Repository 
The repository is where files' current and historical data are stored, often on a server. Sometimes also called a depot.
Resolve 
The act of user intervention to address a conflict between different changes to the same document.
Reverse integration 
The process of merging different team branches into the main trunk of the versioning system.
Revision 
Also version: A version is any change in form. In SVK, a Revision is the state at a point in time of the entire tree in the repository.
Share
The act of making one file or folder available in multiple branches at the same time. When a shared file is changed in one branch, it is changed in other branches.
Stream 
A container for branched files that has a known relationship to other such containers. Streams form a hierarchy; each stream can inherit various properties (like versions, namespace, workflow rules, subscribers, etc.) from its parent stream.
Tag 
A tag or label refers to an important snapshot in time, consistent across many files. These files at that point may all be tagged with a user-friendly, meaningful name or revision number. See baselines, labels and tags.
Trunk
The unique line of development that is not a branch (sometimes also called Baseline, Mainline or Master)
Update 
An update (or sync, but sync can also mean a combined push and pull) merges changes made in the repository (by other people, for example) into the local working copy. Update is also the term used by some CM tools (CM+, PLS, SMS) for the change package concept (see changelist). Synonymous with checkout in revision control systems that require each repository to have exactly one working copy (common in distributed systems)
Working copy
The working copy is the local copy of files from a repository, at a specific time or revision. All work done to the files in a repository is initially done on a working copy, hence the name. Conceptually, it is a sandbox.
\end{frame}

\subsection{Quellen}
\begin{frame}{Quellen}
\begin{itemize}
\item \url{https://git-scm.com/doc}
\item \url{https://git-scm.com/book/en/v2}
\item \url{https://de.wikipedia.org/wiki/Versionsverwaltung}
\end{itemize}
\end{frame}

\subsection{Lizenz}
\begin{frame}{Lizenz}
\frametitle{Lizenz}
Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)\\	
\url{https://creativecommons.org/licenses/by-nc-sa/3.0/deed.en}
\end{frame}
\end{document}