Redmine | Git Bare Repository Workaround

Die letzten beiden Tage habe ich mich etwas mit Redmine beschäftigt. Das Webinterface für Versionskontrollsysteme hat allerdings eine kleine Macke. Zumindest ist das mein Verständnis des Umstands.

Git-Repositories sind in Redmine nur über Working Copies einzulesen. Der gute Stil (und gitolite) stellt serverseitige Git-Repositories als Bare Repos dar. Bare Repos sind im Grunde nur das, was das .git/ Verzeichnis in jeder Working Copy darstellt. Es befinden sich also keine Klartext Files darin.

Creative Commons by Impact Tarmac

Diese Bare Repos lassen sich in Redmine aber nicht hinzufügen. Ob es einfach technisch nicht machbar ist, oder eine Macke seitens Redmine kann ich nicht ausmachen. Fakt ist allerdings, dass ich momentan dazu gezwungen bin Working-Copies für Redmine vorzuhalten.

Ein bisschen Dokumentation zu lesen hat mich da schon um einiges weiter gebracht. Es gibt unter der Redmine Community anscheinend zwei verbreitete Lösungsansätze.

• Cronjob der alle heilige Zeit auf Änderungen prüft
• Hook in Bare Repos einfügen, welcher auslöst wenn gepushte Änderungen vorliegen

Kurz: Ich entschied mir für die zweite Lösung. Um Ressourcen zu sparen. Oder weniger Cronjobs laufen zu haben. Erschien mir effizienter.

Hook für Bare Repo

In Hook-verzeichnis wechseln. Beispielsweise: /home/git/repositories/repo1.git/hooks/. Richtigen Hook auswählen. post-recieve führt Skripte aus, welche _nach_ dem erhalt von Commits ausgeführt werden.  Das Skript sieht vor, das ServerRepo an einen zentralen Sammelpunkt auszuchecken, Rechte anzupassen und für Redmine schreibbar zu machen.

Werden jetzt neue Commits gepushed, wird automatisch ein neues Repo gecloned und die Änderungen sind sofort in Redmine ersichtlich.

Git | Repositories auf Server anlegen

Ich bin ja zukunftsorientiert. Mir wurde einbläut zukunftsorientierte Software zu verwenden und sich nicht mit Relikten alter Generationen rumzuprügeln. Nachdem die letzten Wochen mit SVN etwas holprig waren, mir allerdings halfen das prinzipielle System einer Versionsverwaltung zu verstehen, tat ich mir Git an. Git. Der Name ist ja erstmal unterirdisch wenn mans so auf sich wirken lässt. Ganz im Gegensatz zum Banner der Projekt-Homepage www.git-scm.com, welches ich sehr nett finde. Aber Schluss mit EyeCandy.

Erstellte gezwungenermaßen freiwillig mit ein paar (Obacht, zwei Links in einem Wort) How-To’s ein Git-Repository auf zwetschge.org. Mithilfe der How-Tos, Gitosis, git-daemon-run und git-core war das relativ schnell geschafft. Allerdings kann ich mir beim besten Willen nicht merken wie ich ein Repository für ein neues Projekt erstelle. An der Stelle setzt der Blogpost an.
Serverside:
$ mkdir /home/git/repositories/project.git #Simpler Ordner
$ cd /home/git/repositories/project.git #Selbsterklärend
$ git --bare init #ServerGitRepo bauen

Clientside:
$ cd /home/Code/OrdermitProjekt
$ git init #Projekt einlesen
$ git add . #Alle Inhalte adden
$ git commit -a -m "Inital commit of Software XY" #LokalCommit
$ git remote add origin git@server.com:project.git #RepoServer in .git hinterlegen
$ git push origin master #Push zum Server


#Bei Verwendung von Gitosis - zuerst:
Gitosis:
$ gitosis-init < /tmp/pubkeyofmember.pub
$ vim gitosis.conf
[group Projectteam]
members = user@host #Letzen Inhalte von Public-SSHKey
writable = project #Projektname abgleitet von project.git
$ git commit -a -m "Gitosis update for new Project" #LokalCommit für Rechte
$ git push #Auf RepoServer pushen