"git.net" gibt's nicht?
0 gefällt mir622 aufrufe
Das Dokument gibt eine Einführung in Git, ein verteiltes Versionskontrollsystem, das seit Jahren große Erfolge in der Softwareentwicklung erzielt. Es werden grundlegende Konzepte und mögliche Anwendungen von Git erläutert sowie der typischen Workflow für Projekte beschrieben, inklusive der Nutzung von Befehlen wie 'git init', 'git clone', 'git add', 'git commit', und 'git push'. Darüber hinaus werden nützliche Tools und Ressourcen zur Vertiefung der Kenntnisse über Git vorgestellt.
"git.net" gibt's nicht?
- 1. Torsten Flatter | inovex GmbH "Git.NET" gibt's 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. Überblick DVCS: Großer Durchbruch in den letzten 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