Last active
October 2, 2016 21:24
-
-
Save aspnetde/511c72e743fb658f71f186df12fca85d to your computer and use it in GitHub Desktop.
Der perfekte Workflow für Pull-Requests (als Werkzeug für Code-Reviews)?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Pull-Requests funktionieren wunderbar für kleinere Sachen: Bugfixes, kleinere Features. | |
| Alles, wo die Anzahl der Changes überschaubar bleibt und sich ein Review in kurzer Zeit | |
| gut bewerkstelligen lässt. Siehe: http://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/ | |
| Die Frage ist, wie man das bei größeren Features organisiert. | |
| Angenommen ein Entwickler bekommt die Aufgabe, ein komplett neues Modul in einer App | |
| zu bauen. Bricht man die Aufgabe – was für die Reviews wichtig ist – in kleine | |
| Einheiten auf, hilft das sicherlich auch schon mal allgemein bei der Strukturierung. | |
| Es ergeben sich also nun, beispielhaft, zwei Tickets: View Model bauen, View bauen. | |
| Er erzeugt abgehend von `develop` einen Branch für das View Model und reicht den | |
| als PR ein. Nun kann er die View nicht ohne View Model bauen. Was also hier tun? | |
| 1) Warten, bis jemand das Review durchführt? | |
| > Blöd, wenn es Freitagnachmittag und er gerade im Flow ist. Was für eine Verschwendung. | |
| 2) Zurück zu develop und weiterbauen? | |
| > Geht nicht, er braucht den letzten Code-Stand. | |
| 3) Nicht von `develop`, sondern vom View Model-Branch abzweigen und den View-Branch | |
| aufmachen? | |
| Das würde technisch gehen, birgt aber das Risiko, dass der erste PR abgelehnt oder | |
| noch mal massiv geändert werden muss. (Gut, hier kann er die Änderungen nachher | |
| rübermergen). | |
| - Empfehlungen? |
@agross Ich brauchte irgendwas, das einen linearen Entwicklungsprozess veranschaulicht. Mir fiel dann die hypothetische test-getriebene Entwicklung des View Models ein, mit nachgelagerter Erstellung der View. Nicht, dass das irgendwie praxisnah wäre. 🙄
Aber am Ende sind wir alle beisammen.
Danke für den Austausch an die Runde 👍
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@agross Na das passt doch. Mit dem Rebase bleibt die Timeline (bei 150 commits ;-)) auch verständlich(er). Schön das jemand gleich ein Konzept, Methode und Tooling anbietet. Wir machen das -ähnlich- bisher manuell, um niemanden zu schocken. Danke! Ich schau mir das mal an.