"git.net" gibt's nicht?

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