Im ersten Teil des Tutorials haben wir uns angesehen, was serverseitige von lokalen Git-Hooks unterscheidet und uns mit pre-receive das erste gebräuchliche serverseitige Skript näher angesehen. Daran knüpfen wir nun an und diskutieren zwei weitere Hooks.

Update

Der update-Hook wird nach dem pre-receive-Hook aufgerufen und funktioniert auch ganz ähnlich wie dieser. Auch update wir ausgeführt, bevor irgend etwas tatsächlich geändert wird, aber der Hook wird für jede gepushte Ref separat aufgerufen. Wenn ein Nutzer also beispielsweise vier Branches pusht, wird update vier Mal ausgeführt. Anders als pre-receive akzeptiert dieser Hook drei Argumente:

• Den Namen der Ref, die aktualisiert wird
• Den alten Objektnamen, der in der Ref gespeichert ist
• Den neuen Objektnamen, der in der Ref gespeichert ist

Dieselben Informationen werden auch an pre-receive übergeben, aber da update für jede Ref separat ausgeführt wird, können wir bestimmte Refs ablehnen und andere erlauben.

#!/usr/bin/env python

import sys

branch = sys.argv[1]
old_commit = sys.argv[2]
new_commit = sys.argv[3]

print "Moving '%s' from %s to %s" % (branch, old_commit, new_commit)

# Abort pushing only this branch
# sys.exit(1)

Der Hook oben gibt einfach den Branch und die alten/neuen Commit-Hashes aus. Wenn wir mehr als einen Branch zum Remote-Repository pushen, sehen wir, wie das print-Statement für jeden Branch ausgeführt wird.

Post-Receive

Der post-receive-Hook wird nach einer erfolgreichen Push-Operation aufgerufen und eignet sich prima zum Absetzen von Benachrichtigungen. In vielen Workflows ist dieser Hook besser für das Anstoßen von Benachrichtigungen geeignet als post-commit, da die Änderungen auf einem öffentlichen Server verfügbar sind statt nur auf der lokalen Maschine des Nutzers. E-Mails an anderen Entwickler und das Antriggern eines Continuous-Integration-Systems sind häufige Anwendungsfälle für post-receive.

Das Skript nimmt keine Parameter, sondern bekommt dieselben Informationen wie pre-receive via Standard-Input gesendet.

Zusammenfassung

In den beiden Artikelreihen zu lokalen und serverseitigen Git-Hooks haben wir gelernt, wie wir diese Skripte nutzen können, um das interne Verhalten zu verändern und um Benachrichtigungen zu empfangen, wenn im Repository bestimmte Ereignisse eintreten.

Darüber hinaus haben wir uns die gebräuchlichsten lokalen und serverseitigen Hooks angesehen, mit denen wir uns an beliebigen Stellen im Entwicklungslebenszyklus einklinken können. Wir wissen nun, wie wir in jedem Stadium der Commit-Erstellung und des git push-Prozesses individuelle Aktionen durchführen können. Mit ein wenig Know-how in Sachen Scripting stehen uns alle Türen offen, in unserem Git-Repo praktisch alles zu machen, was wir uns vorstellen können.

Git und Bitbucket Server effektiv nutzen? Wir sind Ihr Partner!

Kennen Sie Bitbucket Server (vormals Stash), Atlassians Git-Repository-Managementsystem? Bitbucket Server bietet eine zentrale Lösung zum Management des gesamten distributierten Codes: Hier kommen alle Git-Repositories im Unternehmen zusammen, hier finden Entwickler immer die letzte offizielle Version eines Projekts, hier können Projektverantwortliche Berechtigungen kontrollieren, um sicherzustellen, dass die richtigen Nutzer Zugriff auf den richtigen Code haben. Möchten Sie mehr erfahren? Wir sind offizieller Vertriebspartner von Atlassian und einer der größten Atlassian Experts Partner weltweit. Gerne unterstützen wir Sie bei der Evaluierung, Lizenzierung und Adaption von Bitbucket Server.

Übrigens: //SEIBERT/MEDIA bietet auch professionelle Grundlagen- und Aufbau-Workshops zu Git und Bitbucket Server an.

Weiterführende Infos

99 Argumente für Bitbucket Server (Stash) als Git-Repository-Manager
Branch-basierte Git-Workflows adaptieren
Echte Integration: Das Zusammenspiel von JIRA, Stash und Bamboo
Interview: Die Vorteile von Git in der Software-Entwicklung und die Möglichkeiten von Bitbucket Server (Stash)
So funktioniert die Lizenzierung von Atlassian-Produkten