Git Backstage bei Windows Developer

Heute erscheint die neue Ausgabe (7.13) des Magazins „Windows Developer„. Der Themenschwerpunkt der Ausgabe liegt dabei auf dem Thema Git in Verbindung mit dem Visual Studio und Windows.

Die aktuelle Ausgabe von Windows Developer

Die aktuelle Ausgabe von Windows Developer

Passend dazu gibt es von mir in dieser Ausgabe den 6-seitigen Artikel „Git Backstage“ welcher sich mit den physikalischen und logischen Speicherstrukturen und -mechanismen eines Git Repositories beschäftigt. Windows Developer kann dabei für 9,80 € am Kiosk bezogen werden.

Git Workflow

Einer der Vorteile von Git ist die große Freiheit welche einem das System gibt. Einer der Nachteile widerum ist die große Freiheit welche Git bietet. Deshalb sollte man sich für die Entwicklung in einem Git Repository einen Workflow zurechtlegen. Hier sei ein exemplarischer Workflow vorgestellt.

Der Git Standardbranch trägt den Namen „master“. In diesem Branch wird per Definition nichts entwickelt. Soll nun ein Feature implementiert oder ein Bug behoben werden, so wird dafür ein Branch eröffnet. Wenn das Feature im Branch implementiert und getestet ist, so kann es wieder in den „master“-Branch gemergt werden. Branches welche gemergt wurden und nicht mehr benötigt werden können dabei wieder entfernt werden. Das gleiche gilt für alte Tagbranches.

Der Vorteil der sich aus dieser Vorgehensweise ergibt, ist das der „master“ immer relativ stabil bleibt, da nur getestete Änderungen in ihn wandern. Außerdem kann man so mehrere Features parallel entwickeln. Bei der Benennung könnte man sich z.B. an folgendes Schema halten:

Featurebranch: feature-supportTiff
Bugfixbranch: bugfix-invalidFormatHandler
Tagbranch: tag-13.04

Interessant wird es wenn ein Release einer Software ansteht. Hier sollte man von der entsprechenden Software welche in einem Git Repository liegt einen Branch erstellen und diesen entsprechend benennen: z.B. als „tag-13.04“. In diesem Branch wird die Software auf Herz und Nieren getestet und auftretende Fehler behoben. Neue Features werden dabei nicht mehr entwickelt.

Wenn nun ein Fehler auftritt hat man drei Möglichkeiten damit umzugehen. Wenn der Fehler nur in dem Tagbranch auftaucht, wird er dort behoben, indem ein Bugfixbranch erzeugt wird, der Fehler behoben und der Bugfix getestet wird. Anschließend wird er wieder in den Tagbranch gemergt.

Ist der Fehler im „master“-Branch und im Tagbranch des aktuelles Releases enthalten, so wird ein Bugfixbranch vom „master“-Branch erstellt, der Fehler dort behoben und anschließend in den „master“ und in den Tagbranch zurückgemergt.

Dies funktioniert natürlich nur, wenn sich der „master“ und der Tagbranch nicht zu weit auseinander entwickelt haben. Ist der Fehler noch in beiden Branches vorhanden, die Unterschiede zwischen den selbigen aber zu gravierend, muss für jeden der beiden Branches ein Bugfixbranch erstellt werden und der Fehler in diesen Branches separat behoben werden. Anschließend wird das ganze in die entsprechenden Branches zurückgemergt.

Wenn alle gefundenen Fehler im Tagbranch behoben wurden bekommt der entsprechende Commit einen Tag in der Form „13.04“. Sollten später weitere Fehler beseitigt werden so werden diese im entsprechenden Tagbranch behoben und anschließend ein neuer Tag vergeben (z.B. „13.04.1“), welches das Bugfixrelease kennzeichnet.

Das ist natürlich nur ein Vorschlag für einen Workflow, der den eigenen Anforderungen unter Umständen angepasst werden muss. So könnte man für sich entscheiden das kleinere Fehler direkt im „master“-Branch behoben werden. Das liegt dann aber in der Verantwortung des Nutzers, der nach diesem Workflow arbeitet.

PuTTY SSH Schlüssel in OpenSSH Schlüssel umwandeln

Möchte man den privaten SSH Schlüssel welcher mittels des „PuTTY Key Generator“ erzeugt wurde auch in der „Git Bash“ nutzen, so muss man den Schlüssel in das OpenSSH Format bringen.

Der PuTTY Key Generator

Der PuTTY Key Generator

Dazu öffnet man den PuTTY Schlüssel mittels „File“ -> „Load private key“. Anschließend wird der Schlüssel über „Conversions“ -> „Export OpenSSH key“ in eine Datei mit dem Namen „id_rsa“ exportiert. Diese Datei wird dann in den Benutzerordner (z.B. „c:\Users\seeseekey\.ssh\“ unter Windows 7) gelegt. Anschließend kann der Schlüssel auch unter der Git Bash benutzt werden.

Git Repository in Subrepository verwandeln

Auf mactricks.de gibt es eine schöne Anleitung um aus einem Teil eines Git Repositories ein Subrepository zu erzeugen. Allerdings gibt es mit der Variante ein Problem. Wenn man das ganze mehr als zwei oder dreimal machen möchte, wird es mit der Zeit nervig all diese Befehle einzugeben.

Aus diesem Grund habe ich für das Extrahieren eines Subprojektes aus einem Git Repository ein Skript geschrieben:

#!/bin/sh
# extractSubproject <orignal repopath> <new repopath> <subfolder> <new remote (optional)>

# clone repository
git clone --no-hardlinks $1 $2

# extract subproject
cd $2
git filter-branch --subdirectory-filter $3 HEAD
git reset --hard
git remote rm origin
rm -r .git/refs/original/
git reflog expire --expire=now --all
git gc --aggressive
git prune

# Add optional remote and push
if [ "$4" != "" ]; then
git remote add origin $4
  git push origin master
fi

Heruntergeladen werden kann sich das Skript auch unter https://github.com/seeseekey/archive/blob/master/Bash/Git/extractSubproject.sh.

Git Server für mehrere Benutzer einrichten

Wie man Git auf einem Ubuntuserver aufsetzt hatte ich vor einiger Zeit in einem Artikel beschrieben. Nachteil der vorgestellten Methode ist, das sie sich nur für einen Nutzer eignet. Natürlich kann man mit dieser Methode auch mehrere Nutzer zu dem Repositories verbinden, hat damit aber keine Möglichkeit mehr Zugriffsberechtigungen für die Repositories zu setzen.

Als Lösung für das Problem wird Gitolite für die Nutzer und Rechteverwaltung genutzt. Im ersten Schritt werden auf dem Server die notwendigen Pakete installiert:

sudo apt-get install git openssh-server perl

Als nächster Schritt wird der Nutzer angelegt, in welchem Gitolite läuft und in diesen gewechselt:

sudo useradd -m git
sudo su git

Danach geht es auch schon an die Installation von Gitolite:

cd ~
git clone git://github.com/sitaramc/gitolite
mkdir bin
cd gitolite
./install -ln

Anschließend muss der öffentliche SSH Schlüssel von dem Rechner mit welchem auf das System zugriffen werden soll in den Home Ordner des „git“ Nutzers kopiert werden. Anschließend kann das Setup abgeschlossen werden:

cd ~/bin
./gitolite setup -pk $HOME/seeseekey.pub

Damit ist das Setup abgeschlossen und es kann an die Konfiguration gehen. Dazu wird vom Rechner dessen Public Key beim Setup benutzt wurde das entsprechende administrative Repository geklont:

git clone git@192.168.1.128:gitolite-admin

Die Dateistruktur des Repositories sieht dabei wie folgt aus:

conf
  gitolite.conf
keydir
  seeseekey.pub

In dem Verzeichnis „keydir“ sind die SSH Schlüssel enthalten. Um einen Nutzer hinzuzufügen reicht es einfach einen neuen öffentlichen Schlüssel in das Verzeichnis zu legen und das ganze ins Git Repository einzubringen. Die eigentliche Konfiguration der Repositories erfolgt in der „gitolite.conf“ Datei. Diese sieht nach der Erzeugung so aus:

repo gitolite-admin
    RW+     =   seeseekey

repo testing
    RW+     =        @all

Das bedeutet das es zwei Repositores gibt, eines trägt den Namen „gitolite-admin“ und dient der Verwaltung. Das zweite Repository ist „testing“ auf das alle Nutzer zugreifen dürfen. Benötigt man nun ein neues Repository, so fügt man einen neuen „repo“ Abschnitt mit dem Namen und den entsprechenden Rechten hinzu. Sobald das ganze commitet und gepusht wurde, legt Gitolite das neue Repository an. Wenn man bei den Schlüsseln mehrere SSH Schlüssel pro Nutzer wünscht, so legt man dafür am besten eine Verzeichnisstruktur an:

keydir
  seeseekey
    rechner1
      seeseekey.pub
    rechner2
      seeseekey.pub

Möchte man ein Repository löschen so entfernt man es aus der „gitolite.conf“ und löscht es anschließend auch vom Server. Damit hat man eine Lösung für Git Server mit mehren Nutzern und und entsprechender Verwaltung.