# Unsere git commit-message convention

Wir haben uns auf einen globalen Grundsatz für **jegliche** git commit Nachrichten
geeinigt.  
Diese gelten für **alle** Projekte die auf unserem GitLab gehostet sind
oder dort in Zukunft gehostet werden.

# Regelungen

Angelehnt an die von git selbst vorgeschlagenen ganz unten stehenden conventions
sind hier unsere eigenen Regelungen festgehalten:

- **Keine Tracker-Prefixes mehr**  
  Die ursprünglichen Tracker-Informationen wie `[TASK]` oder `[BUGFIX]` aus
  Redmine sind zu vermeiden.

- **Keine Satzzeichen**  
  Beendende Satzzeichen Wie `!` oder `.` sind zu vermeiden.

- **Issues in der Summary als Prefix referenzieren**  
  Sollte dein Commit auf einem Issue beruhen, dann referenziere dies bitte in der
  Commit summary.  
  Dabei spielt die Art des Issues eine große Rolle.  
  - Handelt es sich um einen **Bug**, wird als Prefix `Fix` verwendet  
    `Fix #12345 Lorem ipsum dolor sit amet`
  - Andere Issue-Referenzen werden mit `Close` geprefixt  
    `Close #12345 Lorem ipsum dolor sit amet`

- **Weitere Referenzen im Body**  
  Alle weiteren Issues sollten im Body der Commit message referenziert werden,
  somit bleiben in der Summary nur Issues die auch direkt vom Commit betroffen
  sind stehen.

- **Erster Buchstabe groß**  
  Commit messages sind als Sätze zu betrachten. Also wird der erste Buchstabe
  auch groß geschrieben.

- **Nutze den Imperativ**
  > It’s also a good idea to use the imperative present tense in these messages. In other words, use commands. Instead of “I added tests for” or “Adding tests for,” use “Add tests for.” 

# Wie siehts jetzt aus

Im Großen und Ganzen sieht eine 08/15 commit message für einen Bugfix mit einem
Issue dann so aus:

```code
Fix #0815 burning head quarter with water

Further described in #0816, this commit fixes the burning headquarter
with water. Also mentioned in #0817 and #0818.

  - Will introduce cats
  - and ships
```

Für ein ganz "normales" Issue:

```code
Close #0820 remove cats, replace them with dogs

Dogs are good boys! Proven in #42 and #1337

Side-effects:
  - more barking
  - no more mail due to scared mailmen
  - the office smells funny on rainy days
```

Eine commit message ohne Issue-Referenz wird einfach ohne Prefix geschrieben.

# Weitere Dokumentation von git selbst

[Git - Contributing to a Project](https://git-scm.com/book/ch5-2.html#Commit-Guidelines)

> As a general rule, your messages should start with a single line that’s no more
> than about 50 characters and that describes the changeset concisely, followed
> by a blank line, followed by a more detailed explanation. The Git project
> requires that the more detailed explanation include your motivation for the
> change and contrast its implementation with previous behavior – this is a good
> guideline to follow. It’s also a good idea to use the imperative present tense
> in these messages. In other words, use commands. Instead of “I added tests for”
> or “Adding tests for,” use “Add tests for.”  
> Here is a template originally written by Tim Pope:
> ```
> Short (50 chars or less) summary of changes
> 
> More detailed explanatory text, if necessary.  Wrap it to
> about 72 characters or so.  In some contexts, the first
> line is treated as the subject of an email and the rest of
> the text as the body.  The blank line separating the
> summary from the body is critical (unless you omit the body
> entirely); tools like rebase can get confused if you run
> the two together.
> 
> Further paragraphs come after blank lines.
> 
>   - Bullet points are okay, too
> 
>   - Typically a hyphen or asterisk is used for the bullet,
>     preceded by a single space, with blank lines in
>     between, but conventions vary here
> ```