# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch new
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
#       modified:   zeus.json
#

Hier hätte ich gern eine Liste der Issues, an denen ich aktuell arbeite. Hierfür muss man in Redmine die Rest-Authentification aktivieren und kann dann im Git-Projekt unter .git/hooks/prepare-commit-msg den folgenden Hook hinterlegen:

#!/usr/bin/env python

import sys, socket, urllib2, json

url = 'http://myredmine/issues.json?key=abcd&project_id=myproject&assigned_to_id=me'
socket.setdefaulttimeout(3)

try:
	originalfile = open(sys.argv[1], "r")
	original = originalfile.read()
	originalfile.close()
	messagefile = open(sys.argv[1], "w")
	data = json.load(urllib2.urlopen(url))
	messagefile.write('\n\n')
	for issue in data["issues"]:
		messagefile.write(('# Issue #' + str(issue["id"]) + ' ' + issue["subject"] + '\n').encode('utf-8'))
	if not original.splitlines()[0]:
		messagefile.write(original)
	messagefile.close()
except:
	print "Failed to get issues from Redmine."

Leider habe ich keine wirkliche Erfahrung mit Python, aber immerhin macht das Skript seinen Job: Es lädt mittels Redmine-API die mir zugewiesenen, offenen Tickets herunter und zeigt Nummer und Titel als Kommentare an.

# Issue #2 Find a new issue #1
# Issue #1 Microsoft has a majority market share

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch new
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
#       modified:   zeus.json
#

Nachtrag

Die Commit-Message sollte nur verändert werden, wenn die erste Zeile noch frei ist. Andernfalls kann es zu Problemen mit anderen Programmen wie Git Cola kommen, so dass die Issue-Nummer vor der Commit-Nachricht eingefügt und als Teil dieser Nachricht angesehen wird.

git tag -d release1
git push origin :refs/tags/release1

Sehr angenehm, wenn man mal wieder etwas voreilig war.

<<<<<<< HEAD
customer.setPriority(42);
=======
client.setPriority(32);
>>>>>>> master

Customer oder Client? 42 oder 32? Die richtige Lösung muss aus dem umliegenden Code abgeleitet werden. Hier kann es wie so oft helfen, den letzten gemeinsamen Stand der Versionen zu sehen.

git config --global merge.conflictstyle diff3

Ab sofort erscheint bei Konflikten mittig die ursprüngliche Variante. Durch diese wird ohne weiteres Code-Studium deutlich, welche Änderungen jeweils gemacht wurden und übernommen werden sollten:

<<<<<<< HEAD
customer.setPriority(42);
||||||| merged common ancestors
client.setPriority(42);
=======
client.setPriority(32);
>>>>>>> master

Im Beispiel wurde client in customer umbenannt und die Priorität auf 32 reduziert. Die sinnvolle Lösung ist demnach:

customer.setPriority(32);

Die ursprüngliche Darstellung lässt sich durch den Wert merge wiederherstellen:

git config --global merge.conflictstyle merge

Linus Torvalds und die Commit-Message-Struktur

Contributing:

Please either send me signed-off patches or a pull request with signed-off commits. If you don’t sign off on them, I will not accept
them. This means adding a line that says „Signed-off-by: Name“ at the end of each commit, indicating that you wrote the code and have
the right to pass it on as an open source patch.

See: http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html

Also, please write good git commit messages. A good commit message looks like this:

Header line: explaining the commit in one line

Body of commit message is a few lines of text, explaining things in more detail, possibly giving some background about the issue being fixed, etc etc.

The body of the commit message can be several paragraphs, and please do proper word-wrap and keep columns shorter than about 74 characters or so. That way "git log" will show things nicely even when it's indented.

Reported-by: whoever-reported-it
Signed-off-by: Your Name

where that header line really should be meaningful, and really should be just one line. That header line is what is shown by tools like gitk and
shortlog, and should summarize the change in one readable line of text, independently of the longer explanation.

Quelle: Subsurface-Readme-Datei auf Github

Neben einer knappen Header-Zeile erwartet Herr Torvalds also noch einen ausführlichen Körper, der Details und Hintergründe erläutert. Ein besonders interessantes Detail ist die letzte Zeile: Mit „Signed-off-by“ bürgt der Beitragende dafür, dass er das Recht hat, den übermittelten Code zu den Bedingungen des Projekts bereitzustellen.

Linux: Aus der Sicht der Änderung

Im Linux-Projekt findet man viele Meldungen wie diese:

ARM: davinci: psc: fix incorrect offsets

Quelle: https://github.com/torvalds/linux/commits/master?page=4

Hier wird zunächst eingeschränkt, auf welche Bereiche sich die Änderung bezieht. Die Meldung selbst ist im Präsens und aus Sicht des Commits formuliert. Als Hilfestellung für eine konsequente Umsetzung könnte etwa folgender Einstieg helfen: „Ich bin eine Änderung und…“ Für obiges Beispiel wäre das: „Ich bin eine Änderung und behebe falsche Offsets.“

Doch auch das Vorzeigeprojekt ist nicht immer konsequent.

ARM: davinci: dm646x does not have a DSP domain

Quelle: https://github.com/torvalds/linux/commit/9ab409e402cbfde11e2516be43921954db480f4d

Hier wird anstelle der Änderung ein Problem beschrieben. Dies führt unweigerlich zu Konsistenzproblemen: Füge ich ein Feature hinzu, kann ich keine gleichartige Meldung konstruieren.

WordPress: Keine Module, mehr Menschlichkeit

WordPress hält es mit den Commit-Messages recht ähnlich:

Fix list styling. Props koopersmith, azaozz, trepmal. fixes #19453

Quelle: WordPress-Repository

Auch hier bestimmt die aktive Präsensform das Bild. Allerdings neigen die WordPress-Entwickler zu mehrsätzigen Headern, die offensichtlich sogar Danksagungen enthalten können. Auch das behobene Problem wird direkt mit seiner Nummer benannt, was z.B. Track benutzt, um den entsprechenden Issue direkt als behoben zu markieren. Hier wird allerdings die Sicht einer dritten Person bemüht („the commit fixes…“).

Gnome: Die Entwicklersicht

Bei Gnome beschreiben die meisten Entwickler, was sie taten, als sie die Änderung machten. Dementsprechend wird auch in der Vergangenheitsform geschrieben:

Updated on-screen-keyboard patches (squashed)

Quelle: http://git.gnome.org/browse/gnome-shell/commit/?h=osk

Guideline für Commit-Messages

Die meisten anderen Projekte fallen in eine der oben genannten Kategorien. Dies ist auch nicht verwunderlich, schlussendlich gibt es nur begrenzt viele sinnvolle Varianten. Die Form der Commit-Message lässt sich mit wenigen Fragen fixieren:

1. Modularisierung durch z.B. „Modul:“ am Anfang des Message-Headers?
2. Änderungs- oder Entwicklersicht (Präsens oder Präteritum)? „Fix…“ oder „Fixed…“?
3. Aus Sicht der ersten oder dritten Person? „Fix…“ oder „Fixes…“?
4. Trennzeichen im Header? „Fix a; add b“ oder „Fix a. Add b.“?
5. Groß- und Kleinschreibung oder konsequente Kleinschreibung?
6. Zusätzliche Angaben wie Issue-Nummern?

Klärt man diese Punkte am Anfang des Projektes, erhält man einen schönen Changelog, den man auch auf einer Internetseite präsentieren kann.