Andreas Rehm und Rainer Wolf - 2010. Jeder Benutzer hält ein vollständiges Repository aller Dateien und Commits Zentrale Repositories sind möglich aber.

Präsentation zum Thema: "Andreas Rehm und Rainer Wolf - 2010. Jeder Benutzer hält ein vollständiges Repository aller Dateien und Commits Zentrale Repositories sind möglich aber."—  Präsentation transkript:

1 Andreas Rehm und Rainer Wolf - 2010

2 Jeder Benutzer hält ein vollständiges Repository aller Dateien und Commits Zentrale Repositories sind möglich aber nicht notwendig Arbeiten ohne Serverzugriff und immer in einem Ordner Server-Client Modell nicht notwendig – ein einzelner PC kann alleine mit der Versionsverwaltung arbeiten

3 Mergeing ist einfach Branching und Tagging ist billig und einfach (es sind nur Reference Pointer) Jeder Commit weis auf welchen Dateien er aufbaut – wichtig wegen der Verteilung SHA1 Checksum Prüfung jeder Datei Signieren von Commits mit GPG Submodules helfen bei vielen Unterprojekten Kleine, komprimierte Commits/Checkouts

4 Unterstützung für den Import/Export von fast allen gängigen Versionsverwaltungssystemen Unterstützung mehrerer Protokolle (HTTP(s), SSH, GIT Daemon, Dateifreigabe, E-Mail, Patchsets Bisect – GIT Unterstützung bei der Suche nach Bugs zwischen zwei definierbaren Commits Die dezentrale Verwaltung ermöglicht weitere Projektabläufe und Kontrollen

5 Unterstützung vieler Plattformen Extrem effiziente Speicherung von Objekten (wenn die selbe Datei mehrfach eingecheckt wird existiert sie nur einmal) Dadurch erkennt GIT das Verschieben einer Datei selbst und die Historie bleibt erhalten Im Gegensatz zu SVN speichert GIT immer den kompletten Inhalt und keine Patches – Vergleiche sind sehr schnell

6 Kein partieller Checkout (dafür Submodules) – da immer das vollständige Repository mit Historie geladen wird Designbedingt wird immer das komplette Repository heruntergeladen

7 Ein übliches Beispiel ist die verteilte Entwicklung die durch diese Art von Versionsverwaltungen erleichtert wird Das Beispiel enthält drei Master Repositories Eines für den Architekten (der definiert den Contract und kann alle Module sehen) Eines für den Entwickler für ein Primzahlenmodul Eines für den Entwickler der GUI LateBinding des Primzahlenmodules

8 Jeder der Entwickler bekommt einen bin Ordner mit vorkompiliertem Contract, auf den Sourcecode des Contract und das Repository des Architekten haben Sie nur lesende Rechte Durch Berechtigungen wird das Architekten Repository geschützt Der Code der Entwickler wird in eigenen Repositories gepflegt, der Master verweist auf die jeweilig gültige Kombination Das Layout wird so angelegt, dass ein gemeinsamer BIN Ordner verwendet wird – nur auf diesen hat jeder Zugriff

9 Entwickler 1 Primemodul PrimeProjekt BIN\ IContract.DLL

10 Entwickler 2 GUImodul GUIProjekt BIN\ IContract.DLL

11 Architekten Repository IContractProjektPrimeProjektGUIProjekt BIN\ IContract.DLL *

12 Bitte lese die GIT.docx Anleitung – dort sind hilfreiche weitere Hinweise und Links. Die URLs zu den Projekt Bestandteilen folgen auf den nächsten Seiten.

13 Architekt (alle Module) http://devel.itsolution2.de/gitweb/dotnetug-architect.git http://devel.itsolution2.de/gitweb/dotnetug-architect.git Entwickler 1 (Contract und Prime Modul) http://devel.itsolution2.de/gitweb/dotnetug.git http://devel.itsolution2.de/gitweb/dotnetug.git Entwickler 2 (Contract und GUI) http://devel.itsolution2.de/gitweb/dotnetug-dev2.git http://devel.itsolution2.de/gitweb/dotnetug-dev2.git

14 BIN http://devel.itsolution2.de/gitweb/dotnetug-bin.git http://devel.itsolution2.de/gitweb/dotnetug-bin.git Contract http://devel.itsolution2.de/gitweb/dotnetug-contract.git http://devel.itsolution2.de/gitweb/dotnetug-contract.git GUI http://devel.itsolution2.de/gitweb/dotnetug-gui.git http://devel.itsolution2.de/gitweb/dotnetug-gui.git PRIME http://devel.itsolution2.de/gitweb/dotnetug-prime.git http://devel.itsolution2.de/gitweb/dotnetug-prime.git