Hi! DNUG FN 2 TOBIAS ALLWEIER Dipl. Informatiker (FH) Passionated Software Developer Clean Code Developer.NET Junkie.NET User Group Lead E-Mail tobs@tobs4u.com Blog http://www.tobs4u.com Twitter @Blubern
Road Map Get to know Git 3 START GIT BASICS MERGE / REBASE WORKFLOWS END BRANCHING TFS / GITHUB DEMO VERSIONSVERWALTUNG
Versionsverwaltung Eine Art Zeitmaschine 4 Protokollierung Es kann nachvollzogen werden, wer wann was geändert hat. Wiederherstellung Es können Änderungen jederzeit wieder rückgängig gemacht werden. Archivierung Es können Stände Archiviert werden (Versionen). Koordinierung Koordiniert gemeinsamen Zugriff von mehreren Entwicklern auf Dateien. Gleichzeitige Entwicklung an mehreren Entwicklungszweigen (Branches).
Lokale Versionsverwaltung 1 Sehr einfach, dadurch weitverbreitet 5 Lokales Dateisystem Dateien oder Ordner werden lokal kopiert und unter anderem Namen abgelegt z.b. mit einer Versionsnummer oder einem Datum. Fehleranfällig Zufällig im falschen Verzeichnis, die falsche Datei kopiert, die falsche Datei gespeichert. Keine Protokollierung Beim Speichern wird nicht festgehalten, wer die Datei gespeichert hat und warum. Koordinierung Netzlaufwerk - Gemeinsamer Dateizugriff ist problematisch. Der letzte der speichert, hat gewonnen und überschreibt die Änderungen. Dateisystem Ordnerversion 1 Ordnerversion 2 Ordnerversion 3 Ordner Dateiversion 1 Dateiversion 2 Dateiversion 3
Lokale Versionsverwaltung 2 z.b. RCS & SCCS 6 Lokales Dateisystem Verschiedene Versionen einer Datei können im lokalen Dateisystem gehalten werden. Protokollierung Zu den Dateien welche verwaltet werden gibt es einen Verlauf bzw. eine Historie. Koordinierung Es können keine Projekte ( Repositories ) verwaltet werden sondern nur einzelne Dateien. Gemeinsamer Zugriff problematisch da die Daten nur lokal sind. Wiederherstellung Eine Wiederherstellung kann nur für die einzelne Datei erfolgen. Eine Rücksetzen auf eine bestimmt Version von mehreren Dateien ist nicht möglich. Die Daten sind nur lokal abgelegt. Geht die Festplatte kaputt, verliert man die komplette Historie. Checkout File Local Computer Version Database Version 1 Version 2 Version 3
Zentrale Versionsverwaltung Gilt als der Standard (CVS, SVN, TFVC) 7 Zentraler Server Es können Projekte bzw. Repositories zentral verwaltet werden. Ist der Server nicht verfügbar, kann nicht gearbeitet werden. Verzeichnis Es können ganze Verzeichnisse inklusiver Unterverzeichnisse verwaltet werden. Protokollierung Es gibt zu den einzelnen Dateien eine Historie. Außerdem können Projektstände protokolliert werden (Tag auf ein Verzeichnis). Wiederherstellung Es können nicht nur Dateien zurückgesetzt werden sondern auch ganze Verzeichnisse. Geht der Server kaputt, verliert man die komplette Historie und hat nur noch den Stand welcher auf den Clients ist. Koordinierung Durch den zentralen Server sehen alle, was wann und warum geändert wurde. Berechtigungen können zentral vom Administrator verwaltet werden. Die Entwicklung in verschiedenen Entwicklungszweigen ist möglich (Branches). Computer 1 File / Folder Computer 2 File / Folder Central VCS Server Version Database Version 1 Version 2 Version 3
Verteile Versionsverwaltung Der neue Standard (Git, Mercurial, Bazaar or Darcs) 8 Server (Main) Version Database Verzeichnis Es können ganze Verzeichnisse inklusive Unterverzeichnisse verwaltet werden. Version 1 Version 2 Protokollierung Es gibt zu den einzelnen Dateien eine Historie. Außerdem können Projektstände protokolliert werden (Tag auf ein Verzeichnis). Version 3 Computer 2 File / Folder Wiederherstellung Es können nicht nur Dateien zurückgesetzt werden sondern auch ganze Verzeichnisse. Geht der Server kaputt, verliert man die komplette Historie und hat nur noch den Stand, welcher auf den Clients ist. Koordinierung Durch den zentralen Server sehen alle, was wann und warum geändert wurde. Berechtigungen können zentral vom Administrator verwaltet werden. Die Entwicklung in verschiedenen Entwicklungszweigen ist möglich (Branches). Computer 1 File / Folder Version Database Version 1 Version 2 Version Database Version 1 Version 2 Version 3 Version 3
9 Linus Torvalds Das Team um den Linux_Kernel benutzte BitKeeper. Eine Lizenzänderung der Herstellerfirma bewegte 2005 Linus Torvalds ein eigenes Versionsverwaltungssystem zu schreiben. Namensgebung (Git => Blödmann ) Nur drei Buchstaben kein unix Befehl Linus Torvalds sagte selber spaßeshalber: I'm an egoistical bastard, and I name all my projects after myself. First 'Linux', now 'Git'.. Vorlage BitKeeper & Monotone Git verwendet einige Ideen aus BitKeeper und Monotone aber keinen Quellcode. Es ist ein eigenständiges Versionsverwaltungssystem. Ziele von Git Speed Simple Design Strong support for non-linear development (thousands of parallel branches) Fully distributed Able to handle large projects like the Linux kernel efficiently (speed and data size) Open Source https://git-scm.com
Git Performance 10 Quelle: https://git-scm.com/about/small-and-fast
Grundlagen von Git Ignoriere Dein Wissen über TFVC 11 Fast alle Operation sind lokal Auch ohne Verbindung zum Server kann gearbeitet werden. Alle Ressourcen sind lokal verfügbar ( Performance ). s sind lokal möglich Git stellt Integrität sicher Es ist unmöglich, dass sich die Inhalte von Dateien oder Verzeichnissen ändern, ohne dass Git das mitbekommt. Checksumme - SHA-1 Hash - 9a034128a329f4fb7a53043dd1d1e8f74bfc91fc Hash-Werte dienen der Referenzierens des Inhalts. Snapshots, nicht Diffs Die Art wie Git Daten speichert ist entscheidend. Ein Filesystem Light welches bei jeder Änderung einen Snapshot macht. Die drei Zustände Git kennt bei seiner Arbeit drei zustände die man verstanden haben muss.. Git fügt fast ausschließlich Daten hinzu Fast alle Operationen fügen direkt Daten zur Git Datenbank hinzu. Man kann nichts tun was nicht wieder rückgang gemacht werden kann.
Speichern mit Diffs CVS, Subversion und TFVC 12 Version 1 Version 2 Version 3 Version 4 Version 5 File A Δ A Δ A File B Δ B Δ B Δ B File C Δ C Δ C Δ C File D Δ D Δ D s über die Zeit (t)
Speichern mit Snapshots Git 13 Version 1 Version 2 Version 3 Version 4 Version 5 File A A A A1 A2 File B B1 B2 B2 B3 File C C1 C1 C2 C3 File D D D1 D1 D2 s über die Zeit (t)
Die drei Zustände Git kennt bei seiner Arbeit drei Zustände, die man verstanden haben muss 14 Working Working Directory Staging Area Repository (.git Verzeichnis) git add Directory Staging Area git commit Checkout des Projekts Repository (.git Verzeichnis) Stages Fixes Working Directory Staging Area git commit -a Repository (.git Verzeichnis)
15 Live Demo Git Konsole
Branching in Git Some people refer to Git s branching model as its killer feature 16 Lokale Branches Jeder Entwickler kann lokal auf seinem Rechner einen Branch für sich erzeugen. Sehr klein (41 Byte) Bei den meisten anderen Versionsverwaltungssystemen bedeutet ein Branch eine komplette Kopie des Repository bzw. des Ordners. Bei Git bedeutet es einen Eintrag mit einer SHA-1 Checksumme. Das macht das Arbeiten mit Branches sehr performant. Problemloser und schneller wechseln zwischen Branches
Branching in Git 1 1 mit 3 Dateien 17 commit 98ca9 tree 92ec2 author Scott committer Scott Initial commit of my project size tree (Snapshot) 92ec2 blob 5b1d3 README blob 911e7 LICENSE blob cba0a Test.rb size 5b1d3 911e7 cba0a blob size blob size blob size Read Me The Project License If(a < b) { Hello,. Copyright 2008 }
Branching in Git 2 Drei s im Repository 18 98ca9 34ac2 f30ab commit size commit size commit size tree 92ec2 tree 184ca tree 0de24 author Scott parent 98ca9 parent 34ac2 committer Scott author Scott author Scott Initial commit of my project committer Scott committer Scott Fix bug #5123 Add Feature User Story 25 Snapshot 92ec2 Snapshot 184ca Snapshot 0de24
Branching in Git 3 Der Standard Branch master 19 master 98ca9 34ac2 f30ab Snapshot 92ec2 Snapshot 184ca Snapshot 0de24
Branching in Git 4 Einen neuen Zeiger auf den Stand an dem man arbeitet () 20 master 98ca9 34ac2 f30ab Command: git branch testing testing
Branching in Git 5 Der Head Zeiger, zeigt auf den aktuellen lokalen Branch 21 HEAD master 98ca9 34ac2 f30ab testing
Branching in Git 6 Den Branch wechseln 22 master 98ca9 34ac2 f30ab testing Command: git checkout testing HEAD
Branching in Git 7 Änderungen zum Branch hinzufügen 23 master 98ca9 34ac2 f30ab c2b9e Command: edit NewFeature.cs Command: git commit -a -m Add Feature 1 testing HEAD
Branching in Git 8 In den master Branch wechseln und Änderungen commiten 24 HEAD Command: git checkout master Command: edit Main.cs Command: git commit -a -m Bug Fix 1 master 4bc3a 98ca9 34ac2 f30ab c2b9e testing
Branching in Git 9 Von einem einen Branch erstellen und Änderungen hinzufügen 25 HEAD experimental b2561 Command: git checkout 98ca9 Command: git branch experimental Command: edit Experimental.cs Command: git commit -a -m Experimental master 4bc3a 98ca9 34ac2 f30ab c2b9e testing
Merge / Rebase in Git Es gibt zwei Wege um Änderungen von einem Branch in einen anderen Branch zu überführen 26 Feature 1 C4 C6 C8 C1 C2 C3 C5 C7 Master Feature 1 Rebase + fast forward Merge Feature 1 Merge C4 C6 C8 C1 C2 C3 C5 C7 C4 C6 C8 C1 C2 C3 C5 C7 C9 Do not rebase commits that you have pushed to a public repository. If you follow that guideline, you ll be fine. If you don t, people will hate you, and you ll be scorned by friends and family. Master Master
TFVC-Style Workflow Schwer Skalierbar 5 developer 27 shared repository developer A developer B developer C
Integration-Manager Workflow OpenSource Projekte - GitHub 28 blessed repository developer A public developer B public Integration Manager developer A private developer B private
Dictator and Lieutenants Workflow Große Projekte z.b. Linux 29 dictator blessed repository lieutenant lieutenant developer A developer B developer C developer D
30 Live Demo TFS / GitHub
Viel Spaß mit Git J 31