Github Pull Requests

Natürlich verwenden wir github. Und natürlich haben wir Repositories, die von allen unseren Projekten verwendet werden. Wie organisieren wir die Weiterentwicklung in diesen zentralen Komponenten?

Was alles schief gehen kann…

Wir haben ein Repository, das enthält die Basis für alle unsere Konfiguratoren. Eine Änderung daran hat das Potential, bei vielen Kundenprojekten zu Schwierigkeiten zu führen. Naja, wirklich verhindern kann man das natürlich nur, indem ein Projekt einen Branch dieses Repositories benutzt und in diesen nur bei Bedarf und genug Zeit für Tests aktuelle Änderungen aus master hinein merged.

Aber wie stellt man sicher, dass in den master dieses Repos nicht so häufig Unsinn gepushed wird. Das ist unser Anwendungsfall für Githubs Pull Requests.

Wie man einen simplen commit so kompliziert wie möglich macht ;-)

Bevor wir eine Änderung an dem Repo vornehmen, branchen wir, natürlich.

git checkout -b pull-requests

Dann machen wir unsere Änderungen in diesem lokalen Branch und committen sie:

git commit -m "Pull Requests"

Schliesslich pushen wir die Änderung in einen neuen remote branch:

git push origin pull-requests

In der Antwort gibt git schon einen Hinweis auf Pull-Requests:

Enumerating objects: 6, done.
Counting objects: 100% (6/6), done.
Delta compression using up to 4 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 995 bytes | 995.00 KiB/s, done.
Total 4 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
remote: 
remote: Create a pull request for 'pull-requests' on GitHub by visiting:
remote:      https://github.com/OC-Git/OC-Git.github.io/pull/new/pull-requests
remote: 
To https://github.com/OC-Git/OC-Git.github.io.git
 * [new branch]      pull-requests -> pull-requests

Auch in der Web-Oberfläche erscheint der Hinweis, dass ein Pull-Request erstellt werden kann (obwohl wir hier noch den master-Branch eingestellt haben):

Ein Klick auf Compare & pull request führt sofort auf einen neuen Pull Request:

Hier kann man jetzt Reviewers zuordnen, also Kollegen, die sich diesen Request ansehen sollen. Dann wird der Request gespeichert und steht zur Diskussion bereit:

Die Commits sind aufgeführt, die Reviewer können jetzt kommentieren und man kann diskutieren. Ist alles geklärt, werden die Reviewer den Pull Request approven. Dann kann der Pull Requests gemerged werden und sieht anschliessend so aus:

Jetzt bitte noch aufräumen! Der remote feature branch kann direkt aus dem Pull Request gelöscht werden, der lokale einfach über (vorher schalten wir noch um auf master):

git checkout master
git pull
git branch -d pull-requests