# pull request

Ein **pull request** ist eine Bitte, eine Reihe von Änderungen einzuspielen. Die Arbeitsweise läuft meist wie folgt:

  - Entwickler [forkt](https://help.github.com/articles/fork-a-repo) das Repository
  - Entwickler erstellt einen separaten branch, dessen Name das Problem beschreibt. Wenn ein Problem in _foo_ in der _bar_-Komponente gelöst wird, dann z.B. mit `git branch fix-foo-bar`. Für ganz einfache Änderungen braucht ihr das nicht unbedingt. Wer bereits erstellte commits umändern will, muss [etwas tricksen](http://stackoverflow.com/a/1628584/35070).
  - Entwickler korrigiert Probleme / schreibt Erweiterungen. Dabei kann man ruhig mehrere Commits erstellen. Optimal ist, wenn jeder Commit eine kleinere Änderung ist, z.B.
    - lasse foo weiterlaufen, falls bar ausfällt
    - Unittest für Fehler in foo.bar
    - Korrigiere bar-Komponente in foo
    - Aktualisiere Dokumentation von foo.bar für häufige Fehlerursachen
  - Entwickler pusht seine Änderungen zum eigenen Repository.
  - Entwickler klickt auf den `Pull Request`-Button und gibt eine Nachricht ein.
  - _Maintainer_ schaut sich die Änderungen, verlangt ggf. Verbesserungen
  - Maintainer spielt die Änderungen in die Software ein.

[Mehr zu pull requests auf github.](https://help.github.com/articles/using-pull-requests)

# pull request-Nachricht

Die Nachricht eines pull-Requests sollte aus folgenden Informationen bestehen:

  - Eine Zusammenführung (1 Satz), was der pull request macht (`Korrigiere foo.bar, wenn baz passiert`). Der Titel ist eine Kurzform davon (`Korrigiere foo.bar`).
  - Wenn möglich einen Verweis auf das issue. Am besten einfach indem man (closes #42) an den Titel anhängt.
  - Eine kurze Beschreibung, wie das Problem diagnostiziert wurde, oder wofür das Feature nützlich ist, etwa `Wenn baz in einer Vollmondnacht gilt und foo zwei Anfragen kurz hintereinander bekommt, wird in foo.bar der Zugriff nicht richtig serialisiert.`

## So nicht

`Geänderte Dateien: foo/bar.h, foo/bar.c / foo/bar/README, foo/components.c, foo/util.h`

Diese Information wird automatisch generiert. Klickt einfach auf _diff_, um sie selber zu sehen.

```
Titel: Issue #42
Text: #42
```

Der pull request sollte allein aussagekräftig sein.

```
Titel: Die bar-Komponente in foo ist manchmal fehlerhaft. Dieser pull request fix...
Text: ...t sie, wenn baz eintritt.
```

Titel und Text müssen alleine aussagekräftig sein. Nicht jeder liest sie zusammen.

```
Titel: Korrigiere bar-Komponente
Text: Dieser pull request korrigiert foo.bar, wenn baz passiert.
      Außerdem wird der bug #42 (Fehler beim Aufbauen der Netzwerkverbindung) gelöst
      Weiterhin wird in der xy-Komponente jetzt facebook unterstützt
```

Ein pull Request sollte ein Thema haben. Erstelle mehrere Branches (mit [code]git checkout -b[/code]) für mehrere Änderungen.

## diffs

Manche Projekte (wie z.B. lxc) wollen lieber diffs haben. Dafür erstellt man einen oder mehrere git-commits mit der Option `-s` und ruft dann `git format-patch` auf:

```
# Änderungen im Editor machen
git ci -a -s -m 'Fixed stuff'
git format-patch -n HEAD^
```

Der Patch ist dann in der Datei `0001-fixed-stuff.patch`.