Warning: Undefined array key 2 in /var/www/html/lib/plugins/markdowku/syntax/ulists.php on line 79

Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/lib/plugins/markdowku/syntax/ulists.php:79) in /var/www/html/inc/Action/Export.php on line 109

Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/lib/plugins/markdowku/syntax/ulists.php:79) in /var/www/html/inc/Action/Export.php on line 109

Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/lib/plugins/markdowku/syntax/ulists.php:79) in /var/www/html/inc/Action/Export.php on line 109
# 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`.