Upload
inovex-gmbh
View
302
Download
0
Embed Size (px)
DESCRIPTION
Vortrag von Torsten Flatter auf der BASTA! 2012
Citation preview
Torsten Flatter | inovex GmbH
"Git.NET" gibt's nicht?
Vorstellung
• Torsten Flatter
• inovex GmbH
• .NET / C# seit 2004
• VSS, CVS, SVN,
TFS, hq, git
• Enterprise-Umfeld
Agenda
• Überblick
• Grundlagen
• Einsatzbereiche
• Tools
Fragen und Antworten
• Fragen bitte gleich stellen!
• Grundsatz-Diskussionen am Ende
Überblick
DVCS: Großer
Durchbruch in den
letzten Jahren
• Git
• Mercurial
• (Bazaar)
Erfolg von DVCS
• Aus der Praxis geboren (Linux Kernel)
– „Eat your own dogfood!“
– Offline(fähig)
– schnell und effizient
• Katalysator Github
– Leichter Zugang für jeden
• Es macht einfach Spaß!
• Zahllose Anwendungsmöglichkeiten
Next
• Was bedeutet „verteilt“ eigentlich
genau?
• Welche Vorteile habe ich?
• Wie kann das ohne Server
funktionieren?
• Quellenangabe: Bilder aus progit.org
Klassisches Setup
• Historie aller Commits
auf dem Server
• Jeder Client hat genau
seine Arbeitsdaten
• Commits gehen gegen
den Server
• Wie sonst? ;-)
Verteiltes Setup (ein Client)
• Die vollständige(!)
Historie ist auf
jedem Client
• Commits gegen den
Client
• Ebenso Rollbacks,
Branches, Diffs, …
Verteiltes Setup (2 Clients)
• Volle Historie auf
allen Clients
• Jeder Client hat alle
Daten im Repo
(Verzeichnis .git)
• Clients holen sich
Updates (pull)
Verteiltes Setup (viele Clients)
• Bei Teams ≥ 2 ist Server sinnvoll
• Server-Stand „führt“ (per Konvention)
• Austausch zum Server mit push und pull
• Direkter Austausch zwischen Clients weiterhin möglich!
Wie funktioniert das?
• Versions-IDs sind GUIDs
– Keine formalen Konflikte der Commits
– Inhaltliche Konflikte natürlich weiterhin möglich ;-)
• History auf dem „Client“ wird bestimmt durch commits
• History auf dem „Server“ (besser: baseless Repo) wird bestimmt durch pushes
Anwendungsmöglichkeiten
• Versionierung nicht nur von Code …
– Skripte (SQL, cmd, …) Diff!
– Dokumente (Office, UML, Specs!) History!
– Bilder (Logos, Icons, …)
• Backup einfach per git push auf …
– Netzlaufwerk
– anderen Rechner
– USB-Stick „Aktenkoffer“
• Einfach starten, einfach skalieren! …
Zukunft von DVCS
• IMHO: Zukunft aller VCS
– VCS sind Subset von DVCS
Konkret im MS-Umfeld
• Team Foundation Server (langfristig)
Brian Harry (blogs.msdn.com)
„people are asking ‘but, did you implement
DVCS?’. The answer is no, not yet.“
• Git-tf (kurzfristig)
Brian Harry (blogs.msdn.com) „you can create a local Git repo from a TFS
server with git tf clone”
Next
• Typischer Workflow eines neuen
Projekts
Neues Projekt erzeugen
> git init • Erzeugt ein neues
.git-Verzeichnis
• Das Repository
enthält alle Daten
– Dateien
– Historie
– Branches
– …
An Projekt teilhaben
> git clone <origin> • Klont ein existierendes
Repository
• Das Repository
enthält alle Daten
– Dateien
– Historie
– Branches
– …
Dateien hinzufügen
> git add Program.cs • Fügt Dateien dem
index hinzu.
• Notwendig für
– Neue Dateien
– Geänderte Dateien
Dateien versionieren
> git commit -a
-m "erste Version“
• Fügt Dateien der
Historie hinzu
• -a: add (wichtig!)
• -m: Kommentar
• Ab jetzt für andere
Clients über pull
oder push verfügbar
Neuen Stand holen
> git pull origin master
• Holt den letzten
Stand
• „origin“ ist Quelle
von clone
„guten“ Stand sichern
> git push origin master
• Veröffentlicht den
aktuellen Stand
• „origin“ ist Quelle
von clone
Hier ist der große
Vorteil von DVCS:
Nur validierte Stände
werden veröffentlicht
Tools
• Kommandozeile ist OK, aber
es geht auch bequemer:
• TortoiseGit fürs Filesystem
• Msysgit als Unterbau
• Git Source Control Provider
für Visual Studio
Workflows von DVCS
• Viele kleine lokale Commits
• Push erst dann, wenn alles läuft (ggf. rebased)
• Branches möglich, aber nicht immer nötig
• Wenn nötig, dann lokal oder remote möglich
• Lokale Branches sind wirklich nur lokal ;-)
Erste Schritte
• Ausprobieren mit Skripten
• Wenn was nicht klappt
• .git-Verzeichnis einfach wieder löschen
• von vorne anfangen
• Nichts zu verlieren ;-)
Weitere Doku
• Im Netz gibt es unheimlich viel Doku zu git
• Die Quelle: http://git-scm.com/
• Das Buch „Pro Git“: http://git-scm.com/book/de
• Die Referenz
• Selbst in git versioniert