Schlagwort-Archiv: Git

Git Kommandos bei Trunk-Based Development

Git ist mächtig, Git ist vielseitig. Daher reicht es oft nicht aus, einfach drauf los zu committen und irgendwas daraus dann zu veröffentlichen. Um einen absoluten Top-Film zu zitieren (Tremors) “Du musst anfangen im Voraus zu planen!”

Daher sollte ein Branching Model gewählt werden, dass mit der Produktumwelt am besten harmoniert. Ein paar Vorschläge dazu liefert Paul Hammant.

Da neulich ein Freund mit genau der selben Frage für ein neues Projekt auf mich zukam, habe ich ihn an Hammants Artikel verwiesen. Für ihn, und seine Projektsituation passend, wählte er als (noch) Einzelentwickler das Trunk-Based Development Modell. Als Unterstützung bot ich ihm an, die gängigsten Aktionen die hierfür in Git notwendig sind aufzuzeigen.

Trunk-Based Development

Dazu vorab nochmal kurz das Modell erklärt:

trunkbased

Alle Teammitglieder (oder, im Falle meines Freundes, nur eine Person) arbeiten am Trunk. Ein Branch wird nur für ein Major-Release angelegt. Fehlerbehebungen werden per Cherry-Pick aus dem Entwicklungsbranch gezogen. Minor-Releases kennzeichnen weitere Auslieferungen auf den Release-Branches.

Mögliche Aktionen in diesem Modell können nun sein:

  • Neues Projekt anlegen
  • Alltägliches Commit
  • Dem Remote-Branch hinzufügen
  • Major-Release & Tagging
  • Branchwechsel
  • Hotfix in einem Release
  • Minor-Release
  • Neues Major-Release
  • Branch umbenennen
  • Alle Änderungen in das letzte Release nachziehen
  • Änderungen an einem alten Release mit nicht committeten Dateien im Trunk

Zur besseren Darstellung habe ich das ganze in einem Github Repository zur Visuellen Unterstützung veröffentlicht.

https://github.com/tpummer/trunk-based-dev

Neues Projekt anlegen

Das sollte ja eigentlich die einfachste Übung sein. Trotzdem möchte ich es der Vollständigkeit halber anführen:

$ git init
 Initialized empty Git repository in /your/path/to/project/trunk-based-dev/.git/
$ git remote add origin git@github.com/tpummer/trunk-based-dev.git
$ touch README.md
$ git add .
$ git commit -m "First commit"
 [master (root-commit) ed857cc] First commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README.md
$ git push -u origin master
 Counting objects: 3, done.
 Writing objects: 100% (3/3), 217 bytes | 0 bytes/s, done.
 Total 3 (delta 0), reused 0 (delta 0)
 To git@github.com:tpummer/trunk-based-dev.git
 * [new branch]      master -> master
 Branch master set up to track remote branch master from origin.

 

Alltägliches Commit

Wie gerade eben bei der Anlage des initialen Projekts gesehen ist ein normaler Commit keine Hexerei. Mittels

$ git status

kann man sich eine Auflistung der geänderten Dateien anzeigen lassen, welche man einzeln

$ git add README.md

oder einfach alle

$ git add .

dem nächsten Commit hinzufügen kann. Hat man dann alle Dateien für einen Commit gewählt, checkt man diese in die lokale Versionsverwaltung ein.

$ git commit –m “<your commit message>”

Das Ergebnis kann mittels

$ git log

verifiziert werden.

Dem Remote-Branch hinzufügen

Will man dies dann auch noch auf den Remote Branch publishen greift man zu:

$ git push

Da wir vorher einen Upstream für den master Branch festgelegt hatten müssen wir hierbei keine genaueren Pfade angeben. Dies erfolgte mittels

$ git push -u origin master

Major-Release & Tagging

Hurra es ist soweit, wir wollen unser erstes Release an den Mann bringen!

Also müssen wir als Erstes einen Branch anlegen.

$ git checkout –b release1.0.x
 Switched to a new branch 'release1.0.x'

Da aber zukünftig weitere Minor-Releases erfolgen könnten wollen wir jedes einzelne davon taggen, um es zukünftig bequem wiederzufinden.

$ git tag –a v1.0.0 –m “Release Version 1.0.0”

Dies müssen wir natürlich dem Remote Repository wieder mitteilen. Dazu übertragen wir den neuen Branch mit

$ git push –u origin release1.0.x
 Total 0 (delta 0), reused 0 (delta 0)
 To git@github.com:tpummer/trunk-based-dev.git
 * [new branch]      release1.0.x -> release1.0.x
 Branch release1.0.x set up to track remote branch release1.0.x from origin.

Und nicht nur der neue Branch gehört bekanntgegeben, die Tags müssen extra transferiert werden! Wieder einzeln:

$ git push origin v1.0.0
 Counting objects: 1, done.
 Writing objects: 100% (1/1), 174 bytes | 0 bytes/s, done.
 Total 1 (delta 0), reused 0 (delta 0)
 To git@github.com:tpummer/trunk-based-dev.git
 * [new tag]         v1.0.0 -> v1.0.0

oder alle auf einmal

$ git push origin --tag
 Counting objects: 1, done.
 Writing objects: 100% (1/1), 174 bytes | 0 bytes/s, done.
 Total 1 (delta 0), reused 0 (delta 0)
 To git@github.com:tpummer/trunk-based-dev.git
 * [new tag]         v1.0.0 -> v1.0.0

Branchwechsel

Wir wechseln zum Abschluss noch in unseren Entwicklungsbranch um weiterarbeiten zu können:

$git checkout master

Wo wir uns befinden können wir jederzeit mittels

$ git branch
 * master
 release1.0.x

nachsehen. Das Sternchen markiert unseren Standort.

Hotfix in einem Release

Oh nein, es hat sich ein Fehler eingeschlichen! Korrigiert ist er ja flott, aber wie kriege ich das in das Release rüber? Nachdem der Fehler im master Branch ausgebessert und committet wurde, wollen wir nur einen speziellen Commit auch in den Release Branch übertragen.

Dazu sehen wir uns zuerst die Commit ID an

$ git log
 commit 026ec4023e9e55f290b12711918c7c512fb38350
 Author: Thomas Pummer dev@example.org
 Date:   Mon Apr 28 15:08:38 2014 +0200
Fuer Release 1.0.x
commit b5f3a9aeb48fcb0cbaef286d7569f28829192041
 Author: Thomas Pummer dev@example.org
 Date:   Mon Apr 28 15:08:25 2014 +0200
Nicht fuer Release 1.0.x

 

Wir sind also mit commit 026ec4023e an der richtigen Adresse.  Als Nächstes wechseln wir nun in den Release Branch.

$ git checkout release1.0.x
 Switched to branch 'release1.0.x'

Dannach holen wir uns mittels Cherry-Pick genau dieses eine Commit und stecken es abschließend auch in unseren Remote Branch.

$ git cherry-pick 026ec4023e
 [release1.0.x 189c204] Fuer Release 1.0.x
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git push
 Counting objects: 5, done.
 Delta compression using up to 4 threads.
 Compressing objects: 100% (2/2), done.
 Writing objects: 100% (3/3), 307 bytes | 0 bytes/s, done.
 Total 3 (delta 0), reused 0 (delta 0)
 To git@github.com:tpummer/trunk-based-dev.git
 0a648f8..189c204  release1.0.x -> release1.0.x

 

Mittels git log sehen wir, dass der Commit eine neue Commit ID bekommen hat. Um zu identifizieren woher der Commit kam, muss man mit –x einen zusätzlichen Parameter nutzen.

$ git cherry-pick -x c9ed634
 [release1.0.x bd1bee9] cherry with x
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git log
 commit bd1bee920ebee7a0ada2e5723086e8178e15d3c0
 Author: Thomas Pummer dev@example,org
 Date:   Mon Apr 28 15:16:55 2014 +0200
cherry with x
(cherry picked from commit c9ed634612f9f5f31db666d348b88a1563aa31fe)

Minor-Release

Wollen wir nun erneut veröffentlichen funktioniert es wie vorher beim Major Release: In den Branch wechseln

$ git checkout release1.0.x
 Switched to branch 'release1.0.x'

und taggen

$ git tag -a v1.0.1 -m "Release Version 1.0.1"

Auf das Hochladen in das Remote Repository nicht vergessen!

$ git push --tags
 Counting objects: 1, done.
 Writing objects: 100% (1/1), 171 bytes | 0 bytes/s, done.
 Total 1 (delta 0), reused 0 (delta 0)
 To git@github.com:tpummer/trunk-based-dev.git
 * [new tag]         v1.0.1 -> v1.0.1

Minor-Release auschecken

Was müssen wir also tun um an unser Release ranzukommen? Als erstes das Repository klonen:

$ git clone git@github.com:tpummer/trunk-based-dev.git
 Cloning into 'trunk-based-dev'...
 remote: Reusing existing pack: 28, done.
 remote: Total 28 (delta 0), reused 0 (delta 0)
 Receiving objects: 100% (28/28), done.
 Resolving deltas: 100% (1/1), done.

Dannach checken wir direkt den Tag aus:

$ git checkout v1.0.1
 Note: checking out 'v1.0.1'.
You are in 'detached HEAD' state. You can look around, make experimental
 changes and commit them, and you can discard any commits you make in this
 state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
 do so (now or later) by using -b with the checkout command again. Example:
git checkout -b new_branch_name
HEAD is now at bd1bee9... cherry with x

Jetzt haben wir direkt den Stand eines spezifischen getaggten Releases. Wie der Message zu entnehmen ist dies jedoch kein geeigneter Punkt weiterzuarbeiten.  Daher sollte entweder einer der Release-Branches ausgecheckt werden oder wie oben beschrieben ein neuer Branch eröffnet werden. Allerdings würde ein neuer Branch  nicht in unser Trunk-Based Modell passen.

Neues Major-Release

Haben wir nun am master Branch soweit weiterentwickelt dass wir eine neue Major Version herausbringen wollen gehen wir wie bei der ersten Version vor:

$ git checkout -b release1.1.0
 Switched to a new branch 'release1.1.0'
$ git tag -a v1.1.0 -m "Release Version 1.1.0"
$ git push -u origin release1.1.0
 Total 0 (delta 0), reused 0 (delta 0)
 To git@github.com:tpummer/trunk-based-dev.git
 * [new branch]      release1.1.0 -> release1.1.0
 Branch release1.1.0 set up to track remote branch release1.1.0 from origin.
$ git push origin v1.1.0
 Counting objects: 1, done.
 Writing objects: 100% (1/1), 174 bytes | 0 bytes/s, done.
 Total 1 (delta 0), reused 0 (delta 0)
 To git@github.com:tpummer/trunk-based-dev.git
 * [new tag]         v1.1.0 -> v1.1.0

Branch umbenennen

Oh nein der falsche Branch Name! Ist es aufgefallen? Wir wollen ja mehrere Minor Releases in einen Branch unterbringen, weshalb eine Bezeichnung mit einer Wildcard besser gewesen wäre. Also statt release1.1.0 lieber release1.1.x

Nun Lokal geht das ja flott

$ git branch -m release1.1.0 release1.1.x
$ git branch
 master
 release1.0.x
 * release1.1.x

Remote ist die Lösung schon aufwendiger, da dies ein externer Branch ist. Hier hilft nur vorheriges löschen und erneutes pushen

$ git push origin :release1.1.0
 To git@github.com:tpummer/trunk-based-dev.git
 - [deleted]         release1.1.0
$ git push -u origin release1.1.x
 Total 0 (delta 0), reused 0 (delta 0)
 To git@github.com:tpummer/trunk-based-dev.git
 * [new branch]      release1.1.x -> release1.1.x
 Branch release1.1.x set up to track remote branch release1.1.x from origin.

Alle Änderungen in das letzte Release nachziehen

Sind alle Änderungen am master Branch auch für das letzte Release vorgesehen, muss man nicht per Cherry-Pick vorgehen. Man kann den gesamten Branch mergen. Dazu wechselt man zuerst in den Ziel-Branch und holt dann mittels merge Kommando alle Änderungen.

$ git checkout release1.1.x
 Switched to branch 'release1.1.x'
$ git merge master
 Updating 4131cac..5687e2c
 Fast-forward
 README.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Änderungen an einem alten Release mit nicht committeten Dateien im Trunk

Manchmal hat man Datein bereits einem zukünftigen Commit hinzugefügt, dieses aber noch nicht eingecheckt. Möchte man nun den Branch wechseln kommt es zum Fehler, oder die Änderung wird mitgenommen. Zur Vermeidung dessen gibt es ein paar Optionen.

Die simpelste, und am wenigsten Git Magic-lastige, wäre ein Checkout in einem neuen Verzeichnis.

Alternativ kann man die Änderungen auch einfach wegschmeißen

$ git reset –-hard HEAD

Variante Nummer drei  ist der git stash befehl. Damit bunkert man die noch nicht versionierten Änderungen für später und kann eine andere Änderung vorziehen.

Eine mögliche Ausgangslage dafür wären die zwei Datein switch und new:

$ git status
 # On branch master
 # Changes to be committed:
 #   (use "git reset HEAD <file>..." to unstage)
 #
 #       new file:   switch
 #
 # Untracked files:
 #   (use "git add <file>..." to include in what will be committed)
 #
 #       new

Wenn wir nun git stash aufrufen kümmert sich git nur um für ein commit vorgesehene Dateien:

$ git stash
 Saved working directory and index state WIP on master: 5687e2c ready for merge
 HEAD is now at 5687e2c ready for merge
$ git status
 # On branch master
 # Untracked files:
 #   (use "git add <file>..." to include in what will be committed)
 #
 #       new
 nothing added to commit but untracked files present (use "git add" to track)

 

Wollen wir die Datei new also auch stashen müssen wir sie zuerst unter Versionskontrolle stellen:

$ git add .

Dannach können wir auch diese Datei stashen

$ git stash
 Saved working directory and index state WIP on master: 5687e2c ready for merge
 HEAD is now at 5687e2c ready for merge

Wir haben nun 2 stash Objekte bereitliegen, um nach unserer Änderung wieder hervorgeholt zu werden

$ git stash list
 stash@{0}: WIP on master: 5687e2c ready for merge
 stash@{1}: WIP on master: 5687e2c ready for merge
$ git stash apply
 # On branch master
 # Changes to be committed:
 #   (use "git reset HEAD <file>..." to unstage)
 #
 #       new file:   new
 #

 

Ein simples apply holt nur das oberste Element aus dem Stack hervor. Da wir jedoch 2 mal Datein gestashed haben müssen wir diese direkt ansprechen.

$ git stash list
 stash@{0}: WIP on master: 5687e2c ready for merge
 stash@{1}: WIP on master: 5687e2c ready for merge
$ git stash apply stash@{0}
 # On branch master
 # Changes to be committed:
 #   (use "git reset HEAD <file>..." to unstage)
 #
 #       new file:   new
 #
$ git stash apply stash@{1}
 # On branch master
 # Changes to be committed:
 #   (use "git reset HEAD <file>..." to unstage)
 #
 #       new file:   new
 #       new file:   switch
 #

 

Wie zu sehen sind die gebunkerten Änderungen durch ein apply nicht aus der stashing Liste entfernt. Das kann man mit

$ git stash drop

für jeweils wiederum das stash Objekt mit der höchsten Nummer nachholen. Oder man entfernt es direkt mittels der Referen

$ git stash drop stash@{0}

Natürlich hat Stashing eine gewisse Komplexität, und je nach bereits vollzogenen Änderungen will man auch nicht alles Wegschmeißen, weshalb ich im Bedarfsfalle zu erneutem Auschecken (wenn kein Netzwerk dann eben von der lokalen Kopie) tendieren würde. Auch wenn dies eher als Workaround anzusehen ist um Git etwas Komplexität zu nehmen.

Fehlt euch etwas? Dann bitte ab in die Comments, ich werde versuchen es zu ergänzen.
Viel Erfolg mit Git!

Ähnliche Artikel:

Will likely not apply cleanly – Github Fork Queue bereinigen

Wenn man in seinem Github Fork Änderungen aus dem Original nachziehen will kann es unter speziellen Umständen Änderungen geben die sich nicht per Weboberfläche und one-click hinzufügen lassen. Diese sind auf der Oberfläche rot markiert und mit “Will likely not apply cleanly” gekennzeichnet. Um dennoch auf einen ensprechenden Stand zu kommen muss man in der Kommandozeile Hand anlegen:

Erst die eigenen Änderungen rückgängig machen durch zB einen frischen Checkout.

Dann legt man sich einen Link zum Original an:

git remote add ddurst http://github.com/user/project.git
git remote update
git pull ddurst master

Verifizieren mit

git status

Und schließlich in den eigenen Fork damit

git push

Dann kann mit wieder munter mit dem ändern der Sourcen beginnen!

Happy Githubbing

Ähnliche Artikel:

Meine genutzten Plugins aus dem Eclipse Marketplace

Anlässlich der millionsten Installation eines Plugins über den Eclipse Marketplace seit Juni 2010 wollte ich hier ein wenig über die Top10 der gedownloadeten Plugins schreiben, sowie über die von mir eingesetzten Erweiterungen.

01. Subclipse

Subclipse steht in Konkurrenz zu Subversive, welches ich verwende. Auch wenn ich Subclipse schon selbst verwendet habe, bin ich doch überzeugter Subversive Nutzer. Wohl aber nur weil ich das Teil bereits gewöhnt bin.
http://marketplace.eclipse.org/content/subclipse

02. Maven Integration for Eclipse

Unverzichtbar für jedes Maven Projekt. Da ich selbst bei TrayRSS auf Maven setze komme auch ich nicht um m2e herum. Hier bleibt zu resumieren, dass einem das Plugin nicht davor bewahrt sich mit Maven selbst auseinander zu setzen, um das beste für seinen Build zu erzielen. Wer sich mehr mit Maven auseinandersetzen möchte, dem empfehle ich die Dokumentation auf der Maven Seite selbst: http://maven.apache.org/ Diese ist mMn gut aufbereitet. Für tiefersitzende Probleme ist vielleicht folgendes frei erhältliches EBook hilfreich: The Maven Cookbook. Es ist als PDF oder als HTML Version als direktes Nachschlagewerk vorfügbar.
http://marketplace.eclipse.org/content/maven-integration-eclipse

03. Subversive – SVN Team Provider

Das SVN Plugin meiner Wahl. Bisher durchaus ein Usabilitygraus in der Installation, hat der Market die Installation des Plugins erheblich vereinfacht. Subversive bietet nämlich die Möglichkeit über verschiedene Connectoren auf die Repositories zuzugreifen. Diese mussten aus lizenzrechtlichen Gründen über eine extra Installationsseite nachinstalliert werden. Der Market bietet nun nach Installation des Basis-Plugins eine eigene Auswahlseite auf der die gewünschten Connectoren gewählt werden können, sodass Eclipse diese dann ohne weiteres zutun des Benutzers installiert.
http://marketplace.eclipse.org/content/subversive-svn-team-provider

04. EGit – Git Team Provider

“Neu” in der Familie der meiner Plugins ist EGit. Da ich Git noch nicht sehr lange als Versionierungsverwaltung nutze, und erst langsam auf den Geschmack von Git und Github gekommen bin, beschränkt sich meine Erfahrung mit dem Plugin auf ein paar Feldversuche. Git selbst hat mich bereits überzeugt. Und in Zusammenhang mit Open Source finde ich hat Git alle Trümpfe in der Hand. Das Plugin selbst ist etwas komplexer aufgebaut, lässt aber auf den ersten Blick nichts missen. Als Unterstützung für Git-Einsteiger ist es jedoch im Gegensatz zu den SVN-Plugins meiner Meinung nach nicht geeignet. Hier führt der Weg an einem Kommandozeilenbasierten Einstieg nicht vorbei.
http://marketplace.eclipse.org/content/egit-git-team-provider

05. Spring IDE

Dieses Plugin habe ich bisher noch nicht genutzt. Equivalent dazu sind wohl die JBoss Tools. Um Spring Anwendungen zu entwickeln greife ich selbst noch auf die Pluginsammlung von MyEclipse zurück (u.a. die MyEclipse Spring Tools), welche von meinem Arbeitgeber zur Verfügung gestellt wurde.
http://marketplace.eclipse.org/content/spring-ide

06. Eclipse Color Theme

Dieses Plugin nutze ich ebenfalls nicht. Ich habe mir im Zuge dieses Artikels die Funktionsweise des Plugins angesehen, denke aber dass ich es weiterhin nicht einsetzen werde. Ich war bisher noch nie der Typ Mensch, der seine Fenster farblich komplett neu coloriert und muss daher auch den Inhalt des Editors an nichts anpassen.
http://marketplace.eclipse.org/content/eclipse-color-theme/metrics

07. PyDev – Python IDE for Eclipse

Jeder der schon mal in Eclipse eine Python Anwendung entwickelt hat kommt an diesem Plugin eigentlich nicht vorbei. Auch ich nicht. Ich habe damit z.B. Pong programmiert. Mag es zum Python Entwickeln nicht mehr missen, auch wenn die mit Python mitgelieferte IDLE Entwicklungsumgebung durchaus auch seinen Charm und seine Einsatzzwecke hat.
http://marketplace.eclipse.org/content/pydev-python-ide-eclipse

08. FindBugs Eclipse Plugin

Dieses Plugin habe ich aktuell ebenfalls nicht im Einsatz. Das sollte ich allerdings nochmal gründlich überdenken. Erste Versuche damit vor mehr als einem Jahr waren eigentlich ein für meinen Code interessant Erlebnis. FindBugs versucht mittels prüfen auf Bug Pattern Fehlerquellen im Code zu identifizieren durch z.B. falsch genutzte API Aufrufe. Vielleicht gebe ich dem Plugin bald mal wieder einen Versuch.
http://marketplace.eclipse.org/content/findbugs-eclipse-plugin

09. Google Plugin for Eclipse

Mit diesem Plugin habe ich leider noch keine Erfahrung und kann daher nicht viel dazu sagen. Am besten selbst mal nachlesen.
http://marketplace.eclipse.org/content/google-plugin-eclipse

10. JBoss Tools (Helios)

Als ich damals für eine Übung an der TU mit JBoss Seam entwickeln musste hab eich die JBoss Tools kennen gelernt. Sie sind eine mächtige Sammlung an Tools für das Entwickeln von Webanwendungen. Dabei habe ich aber auch ein paar Grenzen kennengelernt. So erzeugen die JBoss Tools in Fundament gegossene Projektstrukturen, was einem späteren Einsatz der Tools auf bereits vorhandene Projekte etwas erschwert. Dennoch bieten sie genug positive Funktionalitäten um derartige Hürden zu überwinden. Und sie sind natürlich perfekt auf den JBoss Server zugeschnitten ;)
http://marketplace.eclipse.org/content/jboss-tools-1

Aus den Top10 habe ich somit bereits 8 Verwendet und verwende 6 immer noch, lediglich 4 weitere Plugins kommen bei mir bewusst zum Einsatz:

Checkstyle

Dieses Plugin dient zur Code Analyse und unterstützt den Entwickler bei der Einhaltung von Coding Conventions.
http://marketplace.eclipse.org/content/checkstyle-plug

GitHub Mylyn Connector

Um Mylyn mit den Github Issues kurzzuschließen
http://marketplace.eclipse.org/content/github-mylyn-connector

Android Configurator m2e

Um Maven mit der Android Entwicklung zu verbinden
http://marketplace.eclipse.org/content/android-configurator-m2e

Android Developement Tools

Die Entwicklungstools für Android sind nicht Teil des Marketplaces sondern direkt zu beziehen:
http://developer.android.com/sdk/eclipse-adt.html

Leider ist der Eclipse Marketplace noch nicht für Eclipse 4.x vorhanden. Auf diese Version bin ich im Zuge des Releases von Java 7 umgestiegen. Wenn jedoch der große Umstieg bevorsteht hoffe ich ihn auch darin wieder nutzen zu können.

Ähnliche Artikel:

HOWTO: Git-Integration in MantisBT

Die letzten Wochen habe ich euch Git näher gebracht und euch gezeigt wie ihr euch einen eigenen Git-Server aufsetzen könnt. Jetzt wollen wir noch Kapital daraus schlagen und Git mit einem Bugtracker verbinden. Ich nutze nun schon seit längerem MantisBT http://www.mantisbt.org welcher mithilfe von ein paar Plugins an Git angebunden werden kann. Dies ermöglicht es einem anhand von Commit Messages Tickets in MantisBT zu steuern und zB ein offenes Ticket zu schließen.

Das Plugin trägt den klingenden Namen Source Control Integration und wurde von John Reese geschrieben. MantisBT selbst setzt das Plugin ein und vermutlich nutzen sie dort auch die Git Variante seit dem Umstieg des Bugtrackers auf Github. Das Plugin selbst besteht aus einem Framework und verschiedene Module für diverse Web-SourceControl Derivate wie z.B. Gitweb, Github, WebSVN. Eine Anleitung wie man dieses Plugin installiert findet sich ebenfalls im Blog von John Reese.

Ich will meine Schritte bei der Installation hier auf Deutsch zur Ergänzung meiner Git Artikel ebenfalls erfassen.

Als erstes galt es das Plugin und seine Abhängigkeiten zu organisieren: Meta Programming und Source Control Integration die entprechenden Repos wurden natürlich per Git geladen und jeweils ins Mantis Plugin Verzeichnis geladen. Im Backend von Mantis konnten diese dann aktiviert werden. Die richtige Reihenfolge konnte ob entsprechend optisch hervorgehobener Abhängigkeiten nicht versemmelt werden.

Nun hat man einen neuen Hauptmenüpunkt: Repositories

In diesem gilt es nun einen Verweis auf sein GitRepository zu erstellen. Name und Typ ausgewählt und schon gehts über den Create Repository Button weiter

MantisBT Sourceintegration Create Repository
MantisBT Sourceintegration Create Repository

Auf der zweiten Seite muss man nun die Daten zum zu überwachenden Repository eintragen

MantisBT Sourceintegration Repository Details
MantisBT Sourceintegration Repository Details

Hierbei wird die URL die auf das Gitwebverzeichnis verweist erst als ganzes eingetragen und dann in Root und Projektteil aufgesplittet. Noch den Master Branch als zu überwachender Branch definiert und schon kanns losgehen. Mit einem klick auf das Repository und dann den Button “Import Latest Data” kann die erfolgreiche Verbindung auch gleich ausgetestet werden.

Der Author empfielt nun einen Cronjob zB per curl einzurichten damit dieser Prozess automatisiert wird. Die ID ist über Mantisbt rauszufinden (Einfach die URL die Mantis nutzt anschaun)

curl http://example.com/mantisbt/plugin.php?page=Source/repo_import_latest&id=XX > /dev/null

Dabei bekomme ich leider eine Fehlermeldung die auf einen ungültigen Sicherheitstoken verweist. In einem Blog Eintrag von Chris Dornfeld habe ich jedoch einen angepassten URL Aufruf dazu gefunden, der nicht auf ein Repository eingeschränkt ist und den Import per Cronjob ermöglicht:

curl http://example.com/mantisbt/plugin.php?page=Source/import&id=all > /dev/null

Fertig aufgesetzt habe ich nun doch etwas Zeit gewonnen, die ich nun ins Projekt statt ins Projektmanagement stecken kann.

Sollten bei euch noch andere Probleme auftreten, möchte ich noch auf eine kleine Hilfestellung im Blog des Authors verweisen, vielleicht werdet ihr ja dort fündig.

Greets

Ähnliche Artikel:

HOWTO: Gitweb für Gitosis, oder wie der Git Server sichtbar wird

Nachdem ich hier erst letztens aufgezeigt habe wie man seinen eigenen Git Server mithilfe von Gitosis aufsetzt, möchte ich heute noch etwas tiefer in die Materie vordingen. Heute soll der Git Server visualisiert werden mithilfe von Gitweb.

Gitweb

Im Prinzip ist Gitweb recht flott installiert wenn man auf die Paketverwaltung der Distribution seines Vertrauens setzt. In meinem Beispielfall ist das Debian und mittels

$ aptitude install gitweb

wird die Software installiert. Damit Gitweb auf die eigenen Repositories zugreifen kann muss natürlich die Konfiguration /etc/gitweb.conf angepasst werden:

# path to git projects (.git) - hier auf das bei der installation von gitosis eventuell angepasste Verzeichnis linken
$projectroot = “/home/git/repositories/”;

# directory to use for temp files
$git_temp = “/tmp”;

# target of the home link on top of all pages
#$home_link = $my_uri || “/”;

# html text to include at home page
$home_text = “indextext.html”;

# file with project list; by default, simply scan the projectroot dir.
# $projects_list = $projectroot;

# Point to projects.list file generated by gitosis. - Hier ist wieder ein anpassung erforderlich wenn das homeverzeichnis wie bei unserem Beispiel angepasst wurde
$projects_list = “/home/git/gitosis/projects.list”;

# stylesheet to use
$stylesheet = “/gitweb.css”;

# javascrip code for gitweb
$javascript = "gitweb.js";

# logo to use
$logo = “/git-logo.png”;

# the ‘favicon’
$favicon = “/git-favicon.png”;

# A list of base urls where all the repositories can be cloned from.
# Easier than having per-repository cloneurl files.
@git_base_url_list = (’git://git.host.example’);

#$strict_export = “true”;

$projectroot – der Pfad zu den von gitosis erzeugten Repositories, in unserem fall /home/git/repositories;
$projects_list – damit wird gitweb gezeigt welche Repos vorhanden sind, entweder indem man auf das root Verzeichnis verweist oder auf eine Datei die eine Liste der Repositories beinhaltet. Verweist man auf die von gitosis erzeugte Projektliste “/home/git/gitosis/projects.list”; kann man über die Konfiguration von gitosis gezielt steuern, welche Repos angezeigt werden sollen.
Projekte die nicht angezeigt werden können mit obiger Konfiguration trotzdem noch durch direkten Aufruf über die Adressliste des Browsers erreicht werden. Soll auch dieser Aufruf unterbunden werden muss man den strict_export parameter auf true setzen, einfach dazu das Kommentarzeichen entfernen.

Nun muss noch im Webserver, in meinem Falle Apache2, richtig konfiguriert werden. Dazu habe ich eine eigene virtuelle Domain eingepflegt in folgender Datei /etc/apache2/sites-available/gitweb:

<VirtualHost *:80>
    ServerAdmin john@example.com
    DocumentRoot /var/cache/git
    ServerName git.example.com
    Alias /gitweb.css /usr/share/gitweb/gitweb.css
    Alias /git-favicon.png /usr/share/gitweb/git-favicon.png
    Alias /git-logo.png /usr/share/gitweb/git-logo.png
    ScriptAlias / /usr/lib/cgi-bin/gitweb.cgi
</VirtualHost>

Abschließend muss noch der Benutzer des Webservers www-data der gitosis gruppe hinzugefügt werden, damit der lesende Zugriff erfolgen kann. Danach wird die neu erstellte Subdomain noch aktiviert

$ a2ensite gitweb

Und Apache neu gestartet

$ /etc/init.d/apache2 reload

Wer cgi noch enabeln muss sollte danach nicht vergessen Apache ganz neu zu starten

$ /etc/init.d/apache2 restart

Und schon sollte der eigene Gitweb Zugriff fertig aufgesetzt sein.

Gitweb in der Gitosisconf

Fehlt natürlich noch die Konfiguration der Repositories um einzelne Projekte in Gitweb auszublenden

Im allgemeinen Bereich definiert hier der vorsichtige User folgendes:

[gitosis]
daemon = no
gitweb = no

Damit schließt man prinzipiell alle Projekte von der Ansicht in Gitweb aus. So wechselt man von einem Opt-Out Verfahren bei dem bei jedem Repo angegeben hätte werden müssen dass es nicht angezeigt werden soll, zu einem Opt-In, bei dem man sich bewusst für das anzeigen in Gitweb entscheiden muss.

Will man nun zB das Repository test in Github angeboten bekommen ist folgender Eintrag notwendig:

[repo test]
description = A repository where tests can take place
owner = testuser
daemon = no
gitweb = yes

Viel Spaß mit Git im Web!

Ähnliche Artikel: