Git und was es kann!

class: title, center, middle

# Version Control ![:scale 10%](./assets/pics/git.png)

## Wie wir gemeinsam mit Dateien arbeiten können

### Philipp Kleer | Institut für Politikwissenschaft | FB 03 | Sommersemester 2022

.social[
[<svg viewBox="0 0 512 512" style="position:relative;display:inline-block;top:.1em;height:1.5em;" xmlns="http://www.w3.org/2000/svg">  <path d="M464 64H48C21.49 64 0 85.49 0 112v288c0 26.51 21.49 48 48 48h416c26.51 0 48-21.49 48-48V112c0-26.51-21.49-48-48-48zm0 48v40.805c-22.422 18.259-58.168 46.651-134.587 106.49-16.841 13.247-50.201 45.072-73.413 44.701-23.208.375-56.579-31.459-73.413-44.701C106.18 199.465 70.425 171.067 48 152.805V112h416zM48 400V214.398c22.914 18.251 55.409 43.862 104.938 82.646 21.857 17.205 60.134 55.186 103.062 54.955 42.717.231 80.509-37.199 103.053-54.947 49.528-38.783 82.032-64.401 104.947-82.653V400H48z"></path></svg>](mailto:philipp.kleer@sowi.uni-giessen.de)     [<svg viewBox="0 0 512 512" style="position:relative;display:inline-block;top:.1em;height:1.5em;" xmlns="http://www.w3.org/2000/svg">  <path d="M294.75 188.19h-45.92V342h47.47c67.62 0 83.12-51.34 83.12-76.91 0-41.64-26.54-76.9-84.67-76.9zM256 8C119 8 8 119 8 256s111 248 248 248 248-111 248-248S393 8 256 8zm-80.79 360.76h-29.84v-207.5h29.84zm-14.92-231.14a19.57 19.57 0 1 1 19.57-19.57 19.64 19.64 0 0 1-19.57 19.57zM300 369h-81V161.26h80.6c76.73 0 110.44 54.83 110.44 103.85C410 318.39 368.38 369 300 369z"></path></svg>](https://orcid.org/0000-0003-1935-387X)     [<svg viewBox="0 0 512 512" style="position:relative;display:inline-block;top:.1em;height:1.5em;" xmlns="http://www.w3.org/2000/svg">  <path d="M105.2 24.9c-3.1-8.9-15.7-8.9-18.9 0L29.8 199.7h132c-.1 0-56.6-174.8-56.6-174.8zM.9 287.7c-2.6 8 .3 16.9 7.1 22l247.9 184-226.2-294zm160.8-88l94.3 294 94.3-294zm349.4 88l-28.8-88-226.3 294 247.9-184c6.9-5.1 9.7-14 7.2-22zM425.7 24.9c-3.1-8.9-15.7-8.9-18.9 0l-56.6 174.8h132z"></path></svg>](https://gitlab.ub.uni-giessen.de/bpkleer)     [<svg viewBox="0 0 512 512" style="position:relative;display:inline-block;top:.1em;height:1.5em;" xmlns="http://www.w3.org/2000/svg">  <path d="M496 128v16a8 8 0 0 1-8 8h-24v12c0 6.627-5.373 12-12 12H60c-6.627 0-12-5.373-12-12v-12H24a8 8 0 0 1-8-8v-16a8 8 0 0 1 4.941-7.392l232-88a7.996 7.996 0 0 1 6.118 0l232 88A8 8 0 0 1 496 128zm-24 304H40c-13.255 0-24 10.745-24 24v16a8 8 0 0 0 8 8h464a8 8 0 0 0 8-8v-16c0-13.255-10.745-24-24-24zM96 192v192H60c-6.627 0-12 5.373-12 12v20h416v-20c0-6.627-5.373-12-12-12h-36V192h-64v192h-64V192h-64v192h-64V192H96z"></path></svg>](https://www.uni-giessen.de/faculties/f03/departments/dps/staff/researchers/kleer?set_language=en)     [<svg viewBox="0 0 448 512" style="position:relative;display:inline-block;top:.1em;height:1.5em;" xmlns="http://www.w3.org/2000/svg">  <path d="M0 32v448h448V32H0zm262.2 334.4c-6.6 3-33.2 6-50-14.2-9.2-10.6-25.3-33.3-42.2-63.6-8.9 0-14.7 0-21.4-.6v46.4c0 23.5 6 21.2 25.8 23.9v8.1c-6.9-.3-23.1-.8-35.6-.8-13.1 0-26.1.6-33.6.8v-8.1c15.5-2.9 22-1.3 22-23.9V225c0-22.6-6.4-21-22-23.9V193c25.8 1 53.1-.6 70.9-.6 31.7 0 55.9 14.4 55.9 45.6 0 21.1-16.7 42.2-39.2 47.5 13.6 24.2 30 45.6 42.2 58.9 7.2 7.8 17.2 14.7 27.2 14.7v7.3zm22.9-135c-23.3 0-32.2-15.7-32.2-32.2V167c0-12.2 8.8-30.4 34-30.4s30.4 17.9 30.4 17.9l-10.7 7.2s-5.5-12.5-19.7-12.5c-7.9 0-19.7 7.3-19.7 19.7v26.8c0 13.4 6.6 23.3 17.9 23.3 14.1 0 21.5-10.9 21.5-26.8h-17.9v-10.7h30.4c0 20.5 4.7 49.9-34 49.9zm-116.5 44.7c-9.4 0-13.6-.3-20-.8v-69.7c6.4-.6 15-.6 22.5-.6 23.3 0 37.2 12.2 37.2 34.5 0 21.9-15 36.6-39.7 36.6z"></path></svg>](https://www.researchgate.net/profile/Benedikt_Kleer)
]

---

# Was passiert oft in Projekten?
Nehmen wir ein einfaches Beispiel: Ihr arbeitet in einer Projektgruppe an einer empirischen Hausarbeit und schreibt auch Code. Ihr habt es bis zu einer finalen Version des Skripts geschafft und macht nun eine finale Kontrolle. 
 
--

---

# Was passiert oft in Projekten?
Dann behebt die eifrige Person C direkt noch Änderung und schickt es wieder an alle Personen der Gruppe.

---

# Was passiert oft in Projekten?
Dann haben Person B und D auch Zeit und bearbeiten noch die finale Version. Person B verplant sich aber dabei und bearbeitete die von A geschickte Version. Person D bearbeitet die von C nochmals korrigierte Version. 
<img src="assets/createdpics/process3-1.png" width="50%" style="display: block; margin: auto;" />
---

# Was passiert oft in Projekten?

Man kann das noch weiterspinnen, was aber klar wird: Es ist ein reines **Chaos** und es fällt schwer den Überblick zu behhalten.

Auch Tools wie JLUbox oder Dropbox sind nur eingeschränkt sinnvoll, da auch hier die synchrone Bearbeitung oftmals zu Problemen führt.

---

# Was macht also ![:scale 10%](./assets/pics/git.png) ?
- **Git** ist eine *Version*-Control: Anwendung in Forschung als auch in IT-Unternehmen
--

- Ziel ist Änderungen in textbasierten Dateien nachverfolgen zu können, also z.B. in Skripten (`.r`, `.rmd`, oder `.md`)
--

- es können verschiedene Personen auch zeitgleich an Dateien arbeiten
--

- Nutzende bearbeiten Dateien lokal, bestätigen ihre Änderungen und senden diese dann an den Server
--

- **Git** speichert die Änderungen und synchronisiert die Datei mit Änderungen von anderen
--

---

# Wie wendet man git an?
Es gibt verschiedene Serverlösungen, die auf git beruhen. Dies sind unter anderem **Gitlab**, **Github** (😒 wurde von Microsoft aufgekauft ) oder auch **Bitbucket**. An der JLU gibt es eine Distribution von [JLU Gitlab](https://gitlab.ub.uni-giessen.de), auf der man sich mit seiner s-/j-/g-Kennung einloggen kann.

Um git verwenden zu können, muss man ein paar Vokabeln verstehen. Diese reichen aber für die Grundlagen vollkommen aus. Um in **Git** arbeiten zu können, muss man ein paar Vokabeln üben.

- Repository (lokal und global (*server-side*))
- Group
- clone
- commit
- pull
- push
- branch

---

# Repository
.font80[
Ein **Repository** (in Gitlab: **Project**) ist wie ein Ordner in der JLUBox oder DropBox. **Repositories** sind durch **Git** synchronisiert und die Versionsverläufe können nachverfolgt werden. Ein **Repository** ist also eine Sammlung von Dateien, deren Bearbeitungsverlauf in Schnappschüssen versioniert wird. Mit **Git** kann man beliebig viele unterschiedliche Repositories verwalten.
]
--
.font80[
Ein **Git-repository** ist z.B. der [Workshop Tidyverse](https://gitlab.ub.uni-giessen.de/bpkleer/mtg21-tidyversek). Dieser beinhaltet die Kursmaterialien zum Workshop. Dies ist die globale Version (*server-side*), die auf **JLU Gitlab** gehostet wird. Man kann die Dateien auf dem Server direkt bearbeiten, das macht man aber in der Regel nicht. Im Üblichen **cloned** man das **Repository** in einen lokalen Ordner, verändert dort die Dateien (in entsprechenden Programmen) und sendet dann die Änderungen an den Server zurück.
]
--
.font80[
.pull-left[
Ein lokales Repository ist einfach ein Ordner, der neben den Dateien einen versteckten Ordner `.git` enthält. In diesem ist hinterlegt, dass dieser Ordner mit einer Server-Version verknüpft ist. 
]
]

.pull-right[
.center[
![:scale 65%](./assets/pics/folder.PNG)
]
]
---

# Group 
Eine **Group** in **Gitlab** ist einfach eine Sammlung verschiedener Repositories in einer Gruppe. So ist z.B. der [Kurs im Sommersemester](https://gitlab.ub.uni-giessen.de/intro-r-spring21) eine solche Gruppe, in der es mehrere Repositories gibt: `group1` bis `group5` und `course-materials`.

.center[
![:scale 70%](./assets/pics/git-group.png)
]
---

# Clone 
Um nun Dateien lokal bearbeiten zu können, muss man die Server-Version lokal speichern und mit **Git** verknüpfen. Dies nennt man **clonen**, da man ein Spiegelbild der Server-Version lokal auf seinem Computer anlegt.

Dies geht schnell über die Eingabeaufforderung (Windows) oder übers Terminal (Mac). Dazu navigiert man einfach in den Ordner, in dem man das *git repository* speichern möchte. In andere Ordner gelangt man mit dem Befehl `cd` (*change directory*). Ich speichere alle git-repositories in einem Ordner namens `gitlab` in `documents`. Hierbei muss beim Navigieren beachten, wo man startet und von dort den Weg über den `cd`-Befehl eingeben. Den Link zum Clonen muss man aus dem jeweiligen Projekt herauskopieren (Button Clone, https- oder ssh-Zugriff wählen)

```bash
cd documents/gitlab/
git clone https://gitlab.ub.uni-giessen.de/bpkleer/mtg21-tidyverse.git
```

---

# Commit 
.font90[
Nachdem man das Repository lokal gecloned hat, kann man die Dateien in dem Ordner bearbeiten. Will man diese neuen Versionen an den Server schicken und allen sichtbar machen, macht man folgenden Dreischritt: **commit**, **pull** & **push**.
]
--
.font90[
Mit **commit** als ersten Schritt geben wir **Git** an, dass die Änderungen, die wir gemacht haben, registriert und in die Server-Versionen hinzugefügt werden sollen Dazu müssen wir zwei Befehle per *Commandline* ausführen. **Wichtig**: Man muss direkt in dem Verzeichnis sein, der das Repository darstellt. In meinem Beispiel muss ich also in das Verzeichnis `mtg21-tidyverse` wechseln, in dem das Repository gecloned wurde.

Mit `git add .` geben wir an, dass alle bearbeiteten Veränderungen in dem Ordner an den Server geschickt werden sollen. Mit `git commit` machen wir daraus eine neue Version und fügen mit `-m` und dem Text in Anführungsstrichen eine kurze Beschreibung hinzu. Jetzt muss man dies nur noch an den Server schicken!
]

--
 
```bash
cd mtg21-tidyverse
git add .
git commit -m "initial status"
```

---

# Pull & Push 
Wenn wir bearbeitete Dateien an den Server schicken wollen, führen wir zuerst *commit* aus. Anschließend führen wir **pull** aus und dann **push**.

Mit **pull** ziehen wir die aktuellste Version vom Server auf unser lokales Verzeichnis. **Wichtig:** Man muss vorher seine lokalen Änderungen mit commit speichern. **Pull** vor **Push** ist wichtig, da ja auch andere Personen an den Dateien arbeiten und evtl. ist die eigene lokale Version gar nicht mehr die aktuellste. Wenn man das vergisst, kann es zum **merge error** kommen. Nachdem man dann die eigenen Änderungen committed hat, und die aktuellste Version gepulled hat, kann man seine Bearbeitung pushen.

```bash
git pull origin main

git push origin main
```

---

# Integration in RStudio
In RStudio können auch direkt git-Repositories gecloned werden. Eventuell fällt dies dem einen oder anderen etwas leichter in der Handhabung. Dazu muss man über `File -> New Project` in RStudio ein neues Projekt erstellen.

.pull-left[
### Schritt 1
Im Menü wählt man dann Version Control aus:
.center[
![:scale 65%](./assets/pics/rstudio-git1.PNG)
]
]

.pull-right[
### Schritt 2
Und dann wiederum Git:
.center[
![:scale 65%](./assets/pics/rstudio-git2.png)
]
]
---

# Integration in RStudio
.font90[
Dann gibt man die Daten des Projekts ein!

.pull-left[

### Schritt 1
*Repository URL*: Link aus gitlab (entweder HTTPS oder SSH)
### Schritt 2
*Project directory name*: meistens automatisch vom Link, kann aber abgeändert werden 
### Schritt 3
*Create project as subdirectory of*: Pfad, in dem das neue Verzeichnis erstellt wird. Kann über *Browse* geändert werden. 
]
]

.pull-right[
.center[
![:scale 75%](./assets/pics/rstudio-git3.png)
]
]
---

# Committen, Pullen & Pushen in RStudio
.font90[
Um das repository in RStudio korrekt handhaben zu können, muss man dann immer die Projekt-Datei aus dem Folder öffnen (`*.Rproj`).
]
--

.pull-left[
.font90[
Nach dem Öffnen der Projektdatei erscheint im Tab, in dem auch das *environment* ist, ein weiterer Reiter namens **Git**. Hier sehen wir auch die drei nötigen Befehle *commit*, *pull* und *push*. 
]
]

.pull-right[
.center[
![:scale 80%](./assets/pics/rstudio-git4.png)
]
]

.pull-left[
.font90[
Wenn man etwas an den Dateien bearbeitet und die Datei gespeichert hat, wird im Reiter **git** sichtbar, dass man diese Datei bearbeitet hat (*modified*)
]
]

.pull-right[
.center[
![:scale 70%](./assets/pics/rstudio-git5.png)
]
]

.font90[
Wie in der Eingabeaufforderung/Terminal auch, muss man nun zuerst *committen*, dann *pullen* und dann *pushen*.
]
---

# Committen, Pullen & Pushen in RStudio
Wenn man nach Änderungen nun auch **Commit** klickt, öffnet sich ein neues Fenster.

.pull-left[
Hier wird angezeigt, welche Datei *modified* wurde, oder z.B. gelöscht (*deleted*) oder hinzugefügt (*added*). Um diese Dateien zu committen, muss einfach ein Haken neben der Datei gesetzt werden. Anschliessend gibt man eine *Commit message* ein und klickt anschließend auf *commit*. Wenn man eine Datei angeklickt hat, sieht man auch im unteren Feld, was in der Datei geändert wurde.

]

.pull-right[
.center[
![:scale 90%](./assets/pics/rstudio-git6.png)
]
]

Nachdem man dann committed hat, drückt man einmal **Pull**, um die derzeit aktuellste Version zu laden und anschließend pusht man seine Änderungen an den Server, in dem man auf **Push** drückt.

---

# Branch
Ein **branch** ist eine Abzweigung in einem Repository. Manche repositories sind so eingestellt, dass jede Person im Repository auf ihrem eigenen **branch** arbeitet und dann am Ende alles final zusammengefügt wird.

Ein neuer Branch kann im entsprechenden Verzeichnis ganz leicht erstellt werden:
```bash
cd documents/gitlab/mtg21-tidyverse
git branch phil
```
--

Um dann in diesem Branch zu arbeiten, muss man in diesen wechseln:
```bash
git checkout phil
```

Mit diesem Befehl kann man in alle Branches wechseln. 
---

# Branch in RStudio
In RStudio kann man einfach in dem Reiter **git** in andere Branches wechseln oder auch neue schaffen.

.center[
![](./assets/pics/rstudio-git7.png)
]
--
 
Hier gibt es jetzt bisher nur den **main**-Branch (den gibt es immer in jedem Projekt!). Man kann über den Button **new branch** einen neuen schaffen und dann über die Auswahl in diesen wechseln.

**Wichtig**: Die Änderungen, die ihr macht, werden immer nur in dem Branch committed, in dem ihr gerade arbeitet!

---

# Weitere Anleitungen

[Installationsanleitung git]()

[Beschreibung von git im Rahmen von JLU-gitlab](https://gitlab.ub.uni-giessen.de/jlugitlab/support/-/blob/master/de/Hilfe.md)

---

class: goodbye, center, middle

# Fragen, Fragen, Fragen?  
.social[
[<svg viewBox="0 0 512 512" style="position:relative;display:inline-block;top:.1em;height:1.5em;" xmlns="http://www.w3.org/2000/svg">  <path d="M464 64H48C21.49 64 0 85.49 0 112v288c0 26.51 21.49 48 48 48h416c26.51 0 48-21.49 48-48V112c0-26.51-21.49-48-48-48zm0 48v40.805c-22.422 18.259-58.168 46.651-134.587 106.49-16.841 13.247-50.201 45.072-73.413 44.701-23.208.375-56.579-31.459-73.413-44.701C106.18 199.465 70.425 171.067 48 152.805V112h416zM48 400V214.398c22.914 18.251 55.409 43.862 104.938 82.646 21.857 17.205 60.134 55.186 103.062 54.955 42.717.231 80.509-37.199 103.053-54.947 49.528-38.783 82.032-64.401 104.947-82.653V400H48z"></path></svg>](mailto:philipp.kleer@sowi.uni-giessen.de)     [<svg viewBox="0 0 512 512" style="position:relative;display:inline-block;top:.1em;height:1.5em;" xmlns="http://www.w3.org/2000/svg">  <path d="M294.75 188.19h-45.92V342h47.47c67.62 0 83.12-51.34 83.12-76.91 0-41.64-26.54-76.9-84.67-76.9zM256 8C119 8 8 119 8 256s111 248 248 248 248-111 248-248S393 8 256 8zm-80.79 360.76h-29.84v-207.5h29.84zm-14.92-231.14a19.57 19.57 0 1 1 19.57-19.57 19.64 19.64 0 0 1-19.57 19.57zM300 369h-81V161.26h80.6c76.73 0 110.44 54.83 110.44 103.85C410 318.39 368.38 369 300 369z"></path></svg>](https://orcid.org/0000-0003-1935-387X)     [<svg viewBox="0 0 512 512" style="position:relative;display:inline-block;top:.1em;height:1.5em;" xmlns="http://www.w3.org/2000/svg">  <path d="M105.2 24.9c-3.1-8.9-15.7-8.9-18.9 0L29.8 199.7h132c-.1 0-56.6-174.8-56.6-174.8zM.9 287.7c-2.6 8 .3 16.9 7.1 22l247.9 184-226.2-294zm160.8-88l94.3 294 94.3-294zm349.4 88l-28.8-88-226.3 294 247.9-184c6.9-5.1 9.7-14 7.2-22zM425.7 24.9c-3.1-8.9-15.7-8.9-18.9 0l-56.6 174.8h132z"></path></svg>](https://gitlab.ub.uni-giessen.de/bpkleer)     [<svg viewBox="0 0 512 512" style="position:relative;display:inline-block;top:.1em;height:1.5em;" xmlns="http://www.w3.org/2000/svg">  <path d="M496 128v16a8 8 0 0 1-8 8h-24v12c0 6.627-5.373 12-12 12H60c-6.627 0-12-5.373-12-12v-12H24a8 8 0 0 1-8-8v-16a8 8 0 0 1 4.941-7.392l232-88a7.996 7.996 0 0 1 6.118 0l232 88A8 8 0 0 1 496 128zm-24 304H40c-13.255 0-24 10.745-24 24v16a8 8 0 0 0 8 8h464a8 8 0 0 0 8-8v-16c0-13.255-10.745-24-24-24zM96 192v192H60c-6.627 0-12 5.373-12 12v20h416v-20c0-6.627-5.373-12-12-12h-36V192h-64v192h-64V192h-64v192h-64V192H96z"></path></svg>](https://www.uni-giessen.de/faculties/f03/departments/dps/staff/researchers/kleer?set_language=en)     [<svg viewBox="0 0 448 512" style="position:relative;display:inline-block;top:.1em;height:1.5em;" xmlns="http://www.w3.org/2000/svg">  <path d="M0 32v448h448V32H0zm262.2 334.4c-6.6 3-33.2 6-50-14.2-9.2-10.6-25.3-33.3-42.2-63.6-8.9 0-14.7 0-21.4-.6v46.4c0 23.5 6 21.2 25.8 23.9v8.1c-6.9-.3-23.1-.8-35.6-.8-13.1 0-26.1.6-33.6.8v-8.1c15.5-2.9 22-1.3 22-23.9V225c0-22.6-6.4-21-22-23.9V193c25.8 1 53.1-.6 70.9-.6 31.7 0 55.9 14.4 55.9 45.6 0 21.1-16.7 42.2-39.2 47.5 13.6 24.2 30 45.6 42.2 58.9 7.2 7.8 17.2 14.7 27.2 14.7v7.3zm22.9-135c-23.3 0-32.2-15.7-32.2-32.2V167c0-12.2 8.8-30.4 34-30.4s30.4 17.9 30.4 17.9l-10.7 7.2s-5.5-12.5-19.7-12.5c-7.9 0-19.7 7.3-19.7 19.7v26.8c0 13.4 6.6 23.3 17.9 23.3 14.1 0 21.5-10.9 21.5-26.8h-17.9v-10.7h30.4c0 20.5 4.7 49.9-34 49.9zm-116.5 44.7c-9.4 0-13.6-.3-20-.8v-69.7c6.4-.6 15-.6 22.5-.6 23.3 0 37.2 12.2 37.2 34.5 0 21.9-15 36.6-39.7 36.6z"></path></svg>](https://www.researchgate.net/profile/Benedikt_Kleer)
]