• Ich gehe nicht eher nach Hause als dass der Bug gefixt ist
• 4 Stunden harte / verzweifelte Arbeit
• Kein Ergebnis
• Feierabend

• 10 min Bugfixen
• 4h Müll aufräumen

• Das muss auch besser gehen

• Metadaten
• Wann?
• Wer?
• Warum? (Kommentar)
• Kennzeichnung von bestimmten Ständen (Label/Tag)
• Arbeit an unterschiedlichen Ständen (Branches)
• Wiederherstellung von Ständen (Checkout)
• Übertragen von Änderungen (Patch / Cherrypick / Rebase)
• Zusammenführen von Änderungen (Merge)
• Vergleich von Versionen (Diff)

• Enthält idealerweise alle relevante Informationen zum Projekt
• Continuous Integration baut darauf auf
• Über Hooks können Personen oder Systeme informiert werden
• Wichtiges Werkzeug für Analyse von Fehlerhäufigkeiten
• Kommentare enthalten oft codierte Informationen

• Eine der ersten Versionsverwaltungen
• Kennt die vollständige Historie einer Datei
• Vollständig: alle von einem Benutzer als relevant definierten Schritte
• Keine Verwaltung über mehrere Dateien
• Keine Unterstützung für Benutzung über das Netzwerk hinweg

• Zentraler Server + Working Copy
  
• Auschecken um Dateien bearbeiten zu können.
• Versionierung von ganzen Dateibäumen
• nicht atomare commits

• Zentraler Server
• atomare Commits
• optimistic Locking

• Distributed Version Control System
• Jeder Benutzer hat sei eigenes Repository
• Alle Repositories sind technisch gleichberechtigt
• Jedes Commit identifizierbar durch einen Hash
• speichert die Folge der Commits, die zu dem aktuellen commit geführt haben
• Branching und Mergen
  
• schnell
• einfach
• Der Gesamte Workflow basiert auf Branching und Merging

• schneller, da lokal gearbeitet wird
  
• mehr commits (>10 pro Tag vs ~1 pro Tag)
• offline arbeiten möglich
• unterstützt flexible Workflows

• Branch pro Feature
• automatische Integration in den CI-Branch (Continuous Integration)
• erlaubt die Neukombination von Featuren, wenn z.B. ein Feature doch nicht deployed werden soll

• Softwareentwicklung ohne Versionsverwaltung ist Pfusch
• Neue Projekte mit Nicht-DVCS machen wenig Sinn

• Anforderungen
• Tests
• Testausführungen
• Dokumentation
• Pläne

• Die Tests für den Bugfix werden auch für den Trunk benötigt
• Welche Änderungen gibt es an den Anforderungen?
• Warum wurde das Handbuch verändert? Und Wann? Und von wem?

• Welche Version des Codes?
• Welche Version der Anforderung?
• Welche Version des Handbuchs?
• Welche Version der Tests

• Gute Integration in Tools
• Spezielle Diffmechanismen
• Spezielle Metadaten
• Meist nur rudimentäre VCS Funktionalität (vergleichbar RCS)
• Versionen über Tools hinaus müssen separat gemanagt werden.
• Vendor Lock-In

• Geringe Acceptance bei nicht technischen Usern
• Nicht sinnvoll bei Binär Daten
• Nicht sinnvoll bei stark volatilen Daten

• generisches VCS als zentrales Tool
• Diverse In-Tool-Versionsverwaltungen
• Gegebenenfalls einzelne Stände vie Export in zentralves VCS

• Dateien oder Verzeichnisnamen mit Versionen
• Änderungshistorie in Dokumenten

• Beispiele
• Ein Refactoring
• Eine neue Klasse und Ihr Test
• Integration von neuen Klassen in bestehenden Code
• Formatierung
• Größere Einheiten können durch Referenzen entstehen
• Referenz auf einen Bug
• Referenz auf ein Feature
• Erleichtert 
• Rückgängig machen
• Transportieren auf andere Branches
• Bewerten von Änderungen

jeschaud@DDEA1846 ~/workspaces/scala/scalaDoodle (master)
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 5 commits.
#
nothing to commit (working directory clean) 

• Was habe ich geändert (semantisch)
  
• Warum habe ich es geändert
• Nicht das Ergebnis eines diffs wiederholen
• Referenzen (Bugs, Requirements)
  
• Maschinenlesbar (kurz, einheitlich, gut parsbar)
• z.B. DPS-4711
• Kommentare sollten auch ohne Referenz verständlich sein
• Inhalt das Bugs / Requirements 
• Warum löst diese Änderung das Problem

• 50 Zeichen
• Zusammenfassung der Änderung

• Mehrzeilig
• Mehrere Absätze
• 72 Zeichen pro Zeile

• Was tut der Code
• Warum tut er es
• evtl. Wie tut er es
• Helfen den Code zu verstehen und zu warten

• Was ist das für eine Änderung
• Warum wird diese Änderung gemacht
• Verweise auf Bug/Requirements
• "Durch diese Änderung wird der Code so geändert, das er Req XY erfüllt"
• Beinhaltet implizit die (potentielle) Notwendigkeit aller vorigen Änderungen