Gabi und Sascha
Kategorien : Alle | Berlin | Bücher | Fotografie | Java | Linkhalde | Weichware | Verfassung

Git dezentraler Ansatz eignet sich hervorragend für die schnelle Entwicklung im CD (Continuous Delivery) Umfeld. Leider wird Git in den meisten Ent­wicklungs­prozessen als zentralistisches Versions­verwaltungs­werk­zeug eingesetzt und verliert damit seinen entscheidenden Vorteil gegenüber Systemen wie zum Beispiel Subversion.

Im CD Umfeld macht es Sinn nur auf master zu entwickeln. Insbesondere wenn zum Beispiel nur Inhouse Projekte entwickelt werden. Branches haben die unangenehme Eigen­schaft, dass sie zu grossen Än­derungen verleiten und damit ein CD System konter­karieren.

Da meiner Meinung nach ein zentrales Repository für CI (Continuous Integration) System wie Jenkins oder Bamboo Sinn macht musst der Prozess des ausschliesslichen entwickeln auf master durch den Einsatz der dezentralen Möglichkeiten von Git umgesetzt werden.

Grösstes Problem ist der Austausch der entwickelten Artefakte zwischen den Entwicklern ohne über ein zentrales Repository zu gehen, wenn Branches nicht gewünscht sind und jeder Commit auf dem zentralen master einen Release Build mit anschliessendem Blau-Grün Deployment auslöst.

Für diese Problem bringt Git die nötigen Werkzeuge von Haus aus mit.

Lokales Repository remote verfügbar machen


    $ mkdir repos
    $ cd repos
    $ git daemon --base-path=. --export-all --verbose

In der erste Zeile wird ein neues Verzeichnis für die Repositories angelegt und dan in das Verzeichnis gewechselt. In dieses Verzeichnis werden später die remote-Repositories mittels git clone oder mittels git fetch geholt.

Entscheidend ist die letzte Zeile. Mittels git daemonwird ein einfacher Git interner Server (Daemon) gestartet. Dieser lauscht per default auf Port 9418.

Die Kommandoschalter und ihre Bedeutung im Einzelnen:

  • --base-path - exportiert Repositories aus dem angegebenen Ordner. In diesem Fall das Verzeichnis in dem der Daemon gestartet wird.
  • --export-all - exportiert alle Repositories im angegebenen Ordner.
  • --verbose - Jede Operation auf dem Server wird auf der Konsole ausgegeben.

Darüber hinaus bietet das daemon Unterkommando noch weitere Schalter. Diese sind im ersten Schritt allerdings nicht wichtig.

Der lauschende Daemon meldet sich mit der PID und der Meldung 'Ready to rumble'.

In einer weiteren Konsole clont der Entwicker isk jetzt ein Repository vom zentralen Git Server im repos Verzeichnis:


    $ cd repos
    $ git clone http://cetral.repo/general_problem_solver.git

Die entfernte Git Clients der Kollegen können jetzt beginnen anonym fetch und clone Operationen auf den Repositories in repos Verzeichnis auszuführen. push Operationen sind nicht möglich. push Operationen müssen explizit mittels Kommandozeilenparameter erlaubt werden.

Lieutenant fetcht mittels remote Verbindung

Angenommen ein Kollege hat bereits den master Branch des zentralen Repositories geclont (origin). Der er aktuell der Lieutenant ist und als einziger in den zentralen master Branch pushen darf, muss er den Entwicklungsstand der Kollegen auf Zuruf mittels fetch ziehen können. Hierzu richtet mittels des Git remote Kommandos eine entfernte Verbindung ein. Dabei wird der Verbindung ein bestimmter Name gegeben.


    $ git init
    Initialized empty Git repository in /home/sascha/repos/.git/
    $ git remote add isk git://192.168.1.127/general_problem_solver

IP Adressen und Namen können einfach per Chat ausgetauscht werden.

Bevor eine remote Verbindung zugefügt werden kann, muss ein leeres Verzeichnis mittels git init initialisiert werden. Ansonsten meldet git remote add … einen Fehler.

Ist das Verzeichnis initialisiert, wird die remote Verbindung eingerichtet.

Wichtig: die Endung .git fehlt im Verzeichnisnamen des entfernten Git Repositories.


    $ git fetch isk

Das Kommando zieht jetzt den Inhalt des entfernte Repositories. Mittels eines git checkout master wird in den master Branch gewechselt. Änderungen können einem Review unterzogen werden. Nach einem erfolgreichen Testlauf werden die Änderungen in das zentrale Repository gepusht. Das CI-System kann die Build- und Deploymentpipeline starten. Wurde das Blue-Green Deployment erfolgreich durchgeführt, kann ein eventuell anhängiges Ticket approved werden.