Einführung in Verteilte Versionskontrollsysteme am Beispiel von Git Diplominformatiker (BA), Git-Benutzer seit 2009 Daniel Böhmer Leibniz-Institut für.

Präsentation zum Thema: "Einführung in Verteilte Versionskontrollsysteme am Beispiel von Git Diplominformatiker (BA), Git-Benutzer seit 2009 Daniel Böhmer Leibniz-Institut für."—  Präsentation transkript:

1 Einführung in Verteilte Versionskontrollsysteme am Beispiel von Git Diplominformatiker (BA), Git-Benutzer seit 2009 Daniel Böhmer Leibniz-Institut für Troposphärenforschung 8. März 2012

2 Verteilte Versionskontrollsysteme/Git ● Ablauf ● Über Versionskontrollsoftware ● Fortschritt durch Git & Co. ● interaktiv/nach Bedarf: – Grundlagen Git mit Demo – Einsatzszenarien/Workflows fürs IfT ● Zwischenfragen erwünscht ● Englisches Vokabular ● Unterlagen elektronisch verfügbar

3 Was ist VCS? ● Engl. version control system (VCS) ● Management von Änderungen an einer/vielen Datei[en] ● Vorrangig Text-, aber auch Binärdateien ● Beispiele: ● RCS – nur 1 Datei, nur lokal ● CVS, MS Visual SourceSafe, SVN – viele Dateien ● Mecurial (Hg), Bazaar, Git – verteilte VCS

4 Wie funktioniert VCS? ● Repository („Archiv“) anlegen ● Dateien anlegen/bearbeiten ● Kleine Einheiten von Änderungen zu Commits zusammenfassen – Beispiele: ● „Fix bug in start script“, 1 Datei bearbeitet ● „Add button to edit user profile“, 2 Datei bearbeitet, 1 Datei hinzugefügt ● Menge an Commits [0..n] = Revision (bestimmter Versionsstand)

5 Was soll VCS leisten? ● Dateien vergleichen und Änderungen protokollieren ● Frühere Versionen von Dateien wiederherstellen ● divergierende Entwicklungspfade pflegen ● Zusammenführen von parallelen Entwicklungen ● Lokale Entwicklung vereinfachen und gemeinschaftliche Entwicklung ermöglichen

6 Was leisten Subversion & Co.? ● Dateien versionieren ● Mehrere Autoren an einem Repository ● Zentrale Verwaltung der Nutzer ● Locking für Dateien gegen gleichzeitiges Editieren ● Verschiedene Entwicklungszweige (SVN: schwierig zu verwenden)

7 Grenzen von Subversion & Co. ● Server-basiert ● Kein Arbeiten ohne Zugang zum Netzwerk ● Arbeitstempo abhängig von Netz und Server ● Keine automatische Lösung von Konflikten bei gleichzeitigen Änderungen in einer Datei ● Ausgerichtet auf lineare Entwicklungsstruktur

8 Verteilte VCS ● Engl. distributed version control system (DVCS) ● Kein Server notwendig ● Jeder »Client« hat gesamte History ● Neue Commits lokal gespeichert und benannt ● Austausch von Commits im 2. Schritt ● »offizielles« Repository durch Popularität

9 Fortschritte durch VCS ● Vollständig lokales Arbeiten ● Nichtlineare Versionshistorie ● automatisiertes Zusammenführen von parallelen Änderungen ● Integration von projektfremden Entwicklern ● Mehrwert für Entwickler ohne eigenen Account ● Zugang zu Änderungen fremder Entwickler ● Integration ohne Administrationsaufwand

10 Woher kommt Git? ● Bedarf durch Entwicklergemeinschaft des Linux- Kernels ● Vorhandene Systeme (Bitkeeper, CVS, SVN …) unbrauchbar ● Komplette Neuentwicklung von Linus Torvalds ● Ziele: verteilter Workflow, sicher, schnell

11 Philosophie von Git ● Alle Dateien in 1 Ordner, Git-Daten in /.git ● Änderungen mit beliebigem Editor durchführen ● Git-Kommandos erreichbar via ● Terminal (empfohlen) ● Grafische Oberfläche für Windows/Linux/Mac ● Plug-In für Editor, z.B. EGit für Eclipse

12 Demo

13 Git visualisiert serve r Alic e Bo b commit pushpull commit push commit pull merg e

14 Gitk: Merging

15 Gitk: Branching

16 Forken ist gut ● Forken (Entwicklungszweig spalten) Voraussetzung für Weiterentwicklung ● Zusammenführen der Zweige sehr einfach

17 Merge für Fortgeschrittene: Rebase Bildquelle: Git Community Book ● Merge: Pfade bleiben nachvollziehbar, Folge: zusätzlicher Merge-Commit ● Rebase: Pfad wird nachträglich »linearisiert«

18 Git ist sicher.

19 ● Datenübertragung über etablierte Protokolle ● SSH ● HTTP(S) ● E-Mail ● Einfache Datenstruktur ● Warnungen vor destruktiven Aktionen ● Trennung von History und Datenspeicher: „gelöschte“ Objekte verbleiben 14d im Speicher

20 Git ist schnell.

21 ● Performance am Bsp. des Linux-Gits (ab 2005): ● `git clone $URL`: 8m 29s ● `git blame README`: ~1s ● `git status` mit 37'000 Dateien:~1s ● `git log | wc -l` (4'140'020 Zeilen):9,7s ● `git log -n 100 | grep -i linux`:<<1s ● `git pull` für 100 Commits von Github:6,4s

22 Arbeiten mit externem Projekt DWD Koordi nator Zentrales IfT-Repo Entwick ler A Entwick ler B

23 Private Eigenentwicklungen pflegen Zentrales IfT-Repo Entwick ler A Rechner von Entwickler Z masterprivate

24 Versionsnummern: SHA1-Hashes ● Nichtlinear → keine inkrementellen Nummern ● SHA1: kryptografischer Hash-Algorithmus ● Eindeutige Prüfsumme (Vgl.: Quersumme) über ● Inhalt aller Dateien ● Ordnerstruktur ● Commit-Metadaten wie Beschreibung, Autor etc. ● Lokal ermittelbar, weltweit eindeutig, 40-stellig, z.B. 582808e9abed50529fb9e7293a8f9eeda ● abkürzbar über die signifikanten Stellen: 5828

25 Start ● Einmalig pro Rechner: ● `git config --global user.name "Daniel Böhmer"` ● `git config --global user.email "boehmer@tropos.de"` ● Pro Projekt: ● Neues Repo anlegen: `git init` ODER ● Vorhandenes Repo klonen: `git clone ssh://mein- server.tropos.de/var/git/projekt.git`

26 Viel Spaß mit Git! ● Folien ● Link-Liste ● Beispiel-Repositories zum Herunterladen ● Auf www.daniel-boehmer.de/git-talk/