archetype | title | linkTitle | author | readings | tldr | outcomes | quizzes | youtube | fhmedia | ||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
lecture-cg |
Intro: Versionskontrolle in der Softwareentwicklung |
Intro |
Carsten Gips (HSBI) |
|
In der Softwareentwicklung wird häufig ein Versionsmanagementsystem (VCS) eingesetzt, welches die Verwaltung
von Versionsständen und Änderungen ermöglicht. Ein Repository sammelt dabei die verschiedenen Änderungen
(quasi wie eine Datenbank der Software-Versionsstände). Die Software *Git* ist verbreiteter Vertreter und
arbeitet mit dezentralen Repositories.
Ein neues lokales Repository kann man mit `git init` anlegen. Der Befehl legt den Unterordner `.git/` im
aktuellen Ordner an, darin befindet sich das lokale Repository und weitere von Git benötigte Dateien
(FINGER WEG!). Die Dateien und anderen Unterordner im aktuellen Ordner können nun der Versionskontrolle
hinzugefügt werden.
Den lokal vorliegenden (Versions-) Stand der Dateien im aktuellen Ordner nennt man auch "Workingcopy".
Ein bereits existierendes Repo kann mit `git clone <url>` geklont werden.
[GitHub](https://github.com) ist nicht Git, sondern ein kommerzieller Anbieter, der das Hosten von
Git-Repositories und weitere Features anbietet.
|
|
|
|
- Was hat wer wann (und wo) geändert? Und warum?
- Ich brauche den Stand von gestern/letzter Woche/...
- Ich will schnell mal eine neue Idee ausprobieren ...
- Ich arbeite an mehreren Rechnern (Synchronisation)
- Wir müssen gemeinsam an der gleichen Codebasis arbeiten.
- Wir arbeiten am Release v42, aber Kunde braucht schnell einen Fix für v40
::: notes
- Filesystem müllt voll mit manuell versionierten
Dateien/Sicherungen ala
file_20120507_version2_cagi.txt
- Ordner/Projekte müssen dupliziert werden für neue Ideen
- Code müllt voll mit auskommentierten Zeilen ("Könnte ja noch gebraucht werden")
- Unklar, wann welche Änderung von wem warum eingeführt wurde
- Unbeabsichtigtes Überschreiben mit älteren Versionen beim Upload in gemeinsamen Filesharing-Bereich :::
:::::: columns ::: {.column width="48%"}
::: ::: {.column width="50%"}
\vspace{10mm}
- [Repository:]{.alert} Datenbank mit verschiedenen Versionsständen, Kommentaren, Tags etc.
\bigskip
- [Workingcopy:]{.alert} Arbeitskopie eines bestimmten Versionsstandes
::: ::::::
::: notes Es gibt ein zentrales Repository (typischerweise auf einem Server), von dem die Developer einen bestimmten Versionsstand "auschecken" (sich lokal kopieren) und in welches sie Änderungen wieder zurück "pushen".
Zur Abfrage der Historie und zum Veröffentlichen von Änderungen benötigt man entsprechend immer eine Verbindung zum Server. :::
::: notes In diesem Szenario hat jeder Developer nicht nur die Workingcopy, sondern auch noch eine Kopie des Repositories. Zusätzlich kann es einen oder mehrere Server geben, auf denen dann nur das Repository vorgehalten wird, d.h. dort gibt es normalerweise keine Workingcopy. Damit kann unabhängig voneinander gearbeitet werden.
Allerdings besteht nun die Herausforderung, die geänderten Repositories miteinander abzugleichen. Das kann zwischen dem lokalen Rechner und dem Server passieren, aber auch zwischen zwei "normalen" Rechnern (also zwischen den Developern).
Hinweis: GitHub ain't no Git! Git ist eine Technologie zur Versionsverwaltung. Es gibt verschiedene Implementierungen und Plugins für IDEs und Editoren. GitHub ist dagegen ein Dienstleister, wo man Git-Repositories ablegen kann und auf diese mit Git (von der Konsole oder aus der IDE) zugreifen kann. Darüber hinaus bietet der Service aber zusätzliche Features an, beispielsweise ein Issue-Management oder sogenannte Pull-Requests. Dies hat aber zunächst mit Git nichts zu tun. Weitere populäre Anbieter sind beispielsweise Bitbucket oder Gitlab oder Gitea, wobei einige auch selbst gehostet werden können. :::
- Repository anlegen (oder clonen)
\bigskip
- Dateien neu erstellen (und löschen, umbenennen, verschieben)
- Änderungen einpflegen ("committen")
- Änderungen und Logs betrachten
- Änderungen rückgängig machen
- Projektstand markieren ("taggen")
\bigskip
- Entwicklungszweige anlegen ("branchen")
- Entwicklungszweige zusammenführen ("mergen")
\bigskip
- Änderungen verteilen (verteiltes Arbeiten, Workflows)
Minimum:
git config --global user.name <name>
git config --global user.email <email>
::: notes Diese Konfiguration muss man nur einmal machen.
Wenn man den Schalter --global
weglässt, gelten die Einstellungen nur
für das aktuelle Projekt/Repo.
Zumindest Namen und EMail-Adresse muss man setzen, da Git diese Information beim Anlegen der Commits speichert (== benötigt!). :::
\bigskip \bigskip
Aliase:
git config --global alias.ci commit
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.st status
git config --global alias.ll 'log --all --graph --decorate --oneline'
::: notes
Zusätzlich kann man weitere Einstellungen vornehmen, etwa auf bunte
Ausgabe umschalten: git config --global color.ui auto
oder Abkürzungen
(Aliase) für Befehle definieren: git config --global alias.ll 'log --all --oneline --graph --decorate'
...
Git (und auch GitHub) hat kürzlich den Namen des Default-Branches von master
auf main
geändert. Dies kann man in Git ebenfalls selbst einstellen:
git config --global init.defaultBranch <name>
.
Anschauen kann man sich die Einstellungen in der Textdatei ~/.gitconfig
oder per Befehl git config --global -l
.
:::
[[Konsole]{.bsp}]{.slides}
-
git init
=> Erzeugt neues Repository im akt. Verzeichnis
\bigskip
-
git clone <url>
=> Erzeugt (verlinkte) Kopie [des Repos unter
<url>
]{.notes}
[[Konsole]{.bsp}]{.slides}
- Git: Versionsmanagement mit dezentralen Repositories
- Anlegen eines lokalen Repos mit
git init
- Clonen eines existierenden Repos mit
git clone <url>
::: slides
Unless otherwise noted, this work is licensed under CC BY-SA 4.0. :::