Vortrag downloaden

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