Your SlideShare is downloading. ×

"git.net" gibt's nicht?

290
views

Published on

Vortrag von Torsten Flatter auf der BASTA! 2012

Vortrag von Torsten Flatter auf der BASTA! 2012

Published in: Lifestyle

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
290
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Torsten Flatter | inovex GmbH"Git.NET" gibts nicht?
  • 2. Vorstellung • Torsten Flatter • inovex GmbH • .NET / C# seit 2004 • VSS, CVS, SVN, TFS, hq, git • Enterprise-Umfeld
  • 3. Agenda• Überblick• Grundlagen• Einsatzbereiche• Tools
  • 4. Fragen und Antworten• Fragen bitte gleich stellen!• Grundsatz-Diskussionen am Ende
  • 5. ÜberblickDVCS: GroßerDurchbruch in denletzten Jahren• Git• Mercurial• (Bazaar)
  • 6. 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
  • 7. Next• Was bedeutet „verteilt“ eigentlich genau?• Welche Vorteile habe ich?• Wie kann das ohne Server funktionieren?• Quellenangabe: Bilder aus progit.org
  • 8. Klassisches Setup • Historie aller Commits auf dem Server • Jeder Client hat genau seine Arbeitsdaten • Commits gehen gegen den Server • Wie sonst? ;-)
  • 9. Verteiltes Setup (ein Client) • Die vollständige(!) Historie ist auf jedem Client • Commits gegen den Client • Ebenso Rollbacks, Branches, Diffs, …
  • 10. Verteiltes Setup (2 Clients) • Volle Historie auf allen Clients • Jeder Client hat alle Daten im Repo (Verzeichnis .git) • Clients holen sich Updates (pull)
  • 11. 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!
  • 12. 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
  • 13. 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! … 
  • 14. Zukunft von DVCS• IMHO: Zukunft aller VCS – VCS sind Subset von DVCS
  • 15. 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”
  • 16. Next• Typischer Workflow eines neuen Projekts
  • 17. Neues Projekt erzeugen> git init • Erzeugt ein neues .git-Verzeichnis • Das Repository enthält alle Daten – Dateien – Historie – Branches – …
  • 18. An Projekt teilhaben> git clone <origin> • Klont ein existierendes Repository • Das Repository enthält alle Daten – Dateien – Historie – Branches – …
  • 19. Dateien hinzufügen> git add Program.cs • Fügt Dateien dem index hinzu. • Notwendig für – Neue Dateien – Geänderte Dateien
  • 20. Dateien versionieren> git commit -a • Fügt Dateien der -m "erste Version“ Historie hinzu • -a: add (wichtig!) • -m: Kommentar • Ab jetzt für andere Clients über pull oder push verfügbar
  • 21. Neuen Stand holen> git pull origin master • Holt den letzten Stand • „origin“ ist Quelle von clone
  • 22. „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
  • 23. Tools• Kommandozeile ist OK, aber es geht auch bequemer:• TortoiseGit fürs Filesystem• Msysgit als Unterbau• Git Source Control Provider für Visual Studio
  • 24. 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 ;-)
  • 25. Erste Schritte• Ausprobieren mit Skripten• Wenn was nicht klappt • .git-Verzeichnis einfach wieder löschen • von vorne anfangen• Nichts zu verlieren ;-)
  • 26. 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

×