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
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
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
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)
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
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)
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
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
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
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
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
Demo
Git visualisiert server pull Conflict?! push push pull merge commit commit Alice commit Bob
Gitk: Merging
Gitk: Branching
Forken ist gut Forken (Entwicklungszweig spalten) Voraussetzung für Weiterentwicklung Zusammenführen der Zweige sehr einfach
Merge für Fortgeschrittene: Rebase Merge: Pfade bleiben nachvollziehbar, Folge: zusätzlicher Merge Commit Rebase: Pfad wird nachträglich»linearisiert«bildquelle: Git Community Book
Git ist sicher.
Git ist sicher. 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
Git ist schnell.
Git ist schnell. 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
Arbeiten mit externem Projekt DWD Manuelles Update Koordinator push Zentrales IfT-Repo pull/push Entwickler A pull/push Entwickler B
Private Eigenentwicklungen pflegen Zentrales IfT-Repo pull/push Entwickler A pull/push Rechner von Entwickler Z master pull private
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
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://meinserver.tropos.de/var/git/projekt.git`
Viel Spaß mit Git! Folien Link Liste Beispiel Repositories zum Herunterladen Auf www.daniel boehmer.de/git talk/