GitBucket: GitHub-Klon fürs Intranet

GitHub ist ein sehr komfortables Portal, wenn es darum geht gemeinsam an Quellcode zu arbeiten. Der Service verwaltet Quellcodes mit Git, zur Dokumentation können Bugs und Wiki-Inhalte bereitgestellt werden. Insbesondere in der Open Source-Szene erfreut sich der Webdienst großer Beliebtheit – für interne Entwicklungen ist er nur bedingt geeignet.

Gegen Bezahlung ist es möglich, private Repositories zu erstellen. Für diese kann festgelegt werden, wer Zugriff erhält – die Daten werden aber dennoch auf Servern des Anbieters gespeichert. Eine weitere denkbare Option ist GitHub Enterprise – die kostenpflichtige Appliance stellt sämtliche von GitHub bekannten Dienste im Intranet zur Verfügung.

Für private Zwecke darf es durchaus etwas kostenloses sein – z.B. GitBucket. Optisch ist die Java-Software stark an GitHub angelehnt und stellt auch die gleichen Grundfunktionalitäten zur Verfügung. Ein Auszug:

  • Öffentliche und private Repositorys
  • Repository-Browser und Datei-Editor
  • Wiki und Bugtracker
  • Fork / Pull Requests

Gegenüber GitHub fehlen derzeit (Release 2.4.1, 06.10.2014) allerdings noch folgende Features:

  • Netzwerk-Graph
  • Statistiken
  • Watch- / Star-Funktion (favorisieren und folgen)
  • Kommentare für Changesets

GitBucket benötigt Tomcat 7.x und liegt als WAR-Archiv vor, welches einfach durch Kopieren in das richtige Verzeichnis bereitgestellt werden kann:

# wget https://github.com/takezoe/gitbucket/releases/download/2.4.1/gitbucket.war -O /var/lib/tomcat/webapps/gitbucket.war

Der Link kann ggf. angepasst werden, falls ein neues Release vorliegt – hierzu empfiehlt sich ein Blick auf die folgende Webseite: [klick mich!]

Auf Systemen mit aktivierten SELinux empfiehlt sich die Zurücksetzung des SELinux-Kontextes:

# restorecon -v /var/lib/tomcat/webapps/gitbucket.war
restorecon reset /var/lib/tomcat/webapps/gitbucket.war context unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:tomcat_var_lib_t:s0

Nach der Installation kann GitBucket über die URL http://$ip:8080/gitbucket erreicht werden. Bequeme Administratoren richten sich über mod_proxy_ajp eine Weiterleitung für Apache ein:

ProxyPass /gitbucket ajp://localhost:8009/gitbucket

Screenshots

Anbei noch einige Screenshots der Software:

Sharing is caring

6 Kommentare Schreibe einen Kommentar

  1. Möchte oder kann man man Java auf dem Server nicht einrichten gibt es auch Alternativen. Gitlab wird sicher schon bekannt sein, aber die Größe des Installationspaketes ist schon fast Abschreckung genug.
    Interessanter finde ich da gogs, welches tatsächlich mit unglaublich wenigen Ressourcen auskommt und schon einiges kann. Soll sogar auf einem RaspberryPi laufen. Statistiken und ähnliches sind noch nicht eingebaut und es ist auch noch eine beta, aber es geht ganz gut voran und der Entwickler reagiert sehr schnell.

  2. Ich betreue eine Instanz von gitlab und bin – nicht nur als Administrator – sehr zufrieden damit. Es ist immer wieder eine Freude, wie reibungslos das Update klappt! Ich nutze dabei noch die „alte Variante“ des manuellen Updates – mittlerweile gibt es fertige Pakete für nahezu jede Distribution.
    Wer sowieso Ruby-Anwendungen am Laufen hat und keinen zusätzlichen Tomcat-Server aufsetzen will, ist mit Gitlab vermutlich gut bedient.

    • Hallo Niko,
      nach dem ersten Update von GitBucket auf zwei Servern (die jeweils nicht funktioniert haben) bin ich auch bei GitLab gelandet. *hust* 🙂

      Beste Grüße,
      Christian.

  3. Ich kann Niko nur zustimmen:
    Ich benutze auch seit nunmehr 8 Jahren Gitlab und bin von der Wartungsarmut und den Features überzeugt.

    Bei meiner ersten Firma haben wir es standalone eingeführt, nachdem wir von SVN über Mercurial schlussendlich bei bei Git hängen geblieben sind. Damals mit in Verbindung mit Redmine zusammen.

    Bei der letzten Firma wo ich war, haben wir ein Gitlab in Verbindung mit Bamboo und Jira aufgezogen. Einmal installiert und praktisch nie wieder Aufwand damit gehabt.

    Aktuell nutze ich Gitlab in Verbindung mit Jenkins und auch hier wird „von Haus aus“ eine Integration mitgeliefert, sodass man aus den Builds direkt auf die entsprechenden Commits abspringen kann etc..

    Vielleicht lohnt es sich, dort auch mal (auf einer VM o.ä.) reinzuschauen. Die Installation ist mittlerweile auch automatisiert(früher war das ein echter Krampf), sodass die Hürde hier auch gering sein sollte.

    • Ah, Integration, dazu habe ich gar kein Wort verloren. Vermutlich, weil es so einfach war ^^

      Hier läuft Gitlab zusammen mit Redmine, Jenkins und ist ans LDAP angebunden, was auch erfreulich einfach funktionierte.
      Das ist nur eine einfache Anbindung ans LDAP, die Enterprise Edition ist da anscheinend mächtiger. Aber sie funktioniert und macht keine Probleme.

Schreibe einen Kommentar