Andreas Rehm und Rainer Wolf

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

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

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

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

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

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

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

Entwickler 1 Primemodul PrimeProjekt BIN\ IContract.DLL

Entwickler 2 GUImodul GUIProjekt BIN\ IContract.DLL

Architekten Repository IContractProjektPrimeProjektGUIProjekt BIN\ IContract.DLL *

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.

Architekt (alle Module) Entwickler 1 (Contract und Prime Modul) Entwickler 2 (Contract und GUI)

BIN Contract GUI PRIME