Skip to content

Home

Jump to bottom
Ralf Stockmann edited this page Nov 30, 2019 · 9 revisions

Spielregeln

Wir folgen den Regeln von GitHub flow (nicht: gitflow). Die sind hier gut erklärt:

Daraus ergibt sich:

  1. Der master branch ist heilig. In ihm darf nur produktiver, getesteter und reviewed Code befinden. Ohne zu zögern geben wir ihn raus, um damit Sendungen zu produzieren.
  2. Sämtliche Erweiterungen, Bugfixes und sonstige Umbauten finden niemals im master statt, sondern immer in einem sinnvoll benannten feature-branch. In master wird also - bis auf in wenigen Ausnahmefällen - nicht commited.
  3. Bevor ein feature-branch angelegt wird, muss im Projektbereich https://github.com/Ultraschall/ultraschall-portable/projects/1 ein Issue dafür angelegt werden, dass das grundsätzliche Ziel menschenlesbar beschreibt. Dieses Issue liegt zunächst in der Spalte "Offen / Ideen" und wird dort diskutiert.
  4. An jedem Issue wird ein Tag angehängt nach dem Muster #Issuenummer, also etwa: #42 - dieses Tag wird dann auch an den korrespondierenden Pull Request gehängt sowie an eventuelle andere Elemente die Tags zu diesem Issue tragen können.
  5. Möchte man ein Feature angehen, so setzt man zunächst "Assignee" des Issues auf den eigenen Namen. Dann legt man einen feature branch an mit einem hinreichend ähnlichen Namen wie das Issue. Jeder feature branch wird vom master abgeleitet.
  6. Hat man einen feature-branch angelegt (und erst dann!), so verschiebt man die Issue-Karte auf den Status "In Arbeit". Es gibt also keinen Branch ohne entsprechende Karte im Projektboard auf dem Status "In Arbeit", und keine Karte in dieser Spalte ohne Branch.
  7. In der Beschreibung des feature-branch setzen wir einen Verweis auf #issue, Ebenso an den Beginn des Titels des Issues, etwa #42 Name des Issue
  8. Wir commiten unsere Änderungen in unserem feature-branch so oft wie sinnvoll, mindestens aber nach jeder Arbeitssession. Ein feature-branch kann jederzeit kaputten oder unproduktiven Code enthalten. Massen-commits über viele Dateien sind zu vermeiden, im Zweifel lieber jede Datei einzeln commiten mit aussagekräftiger Beschreibung.
  9. Wir nutzen das Pull Request Feature von GitHub um die Funkionen in einem feature-branch von anderen testen zu lassen. Die dann hier entstehende Kommunikation ersetzt die bisherige im RocketChat. Die Diskussion erfolgt nie am PR, sondern immer am ursprünglichen Issue. Der Name des PR entspricht im Wesentlichen dem des Issue, zusätzlich beginnt er mit dem Tag-Namen, also etwa: #42 Name des Issue
  10. Wenn der Pull Requestfür ein Issue erfolgt ist, so schieben wir die entsprechende Projektkarte eine Spalte weiter auf Test und Review
  11. Der finale merge request in den master wird nie vom Entwickler selbst, sondern immer von einem anderen Mitglied nach finalem Test/Codereview vorgenommen. Hier wird auch auf ausreichende Dokumentation etc. geachtet. Nach erfolgreichem merge wird der feature-branch gelöscht - die ganze Historie bleibt ja im Git erhalten.
  12. Issues, die sich durch Änderungen in den Settings von REAPER lösen lassen (Änderungen in den .ini Dateien) werden immer mit einem Screenshot illustriert, der das entsprechende Settings-Fenster zeigt.
  13. Ist ein neues Feature in den master gemerged worden, so wird direkt hier im Wiki das Changelog erweitert: https://github.com/Ultraschall/ultraschall-portable/wiki/Ultraschall-Changelog - die GIFs dazu produziert @rstockm

Kontrollregeln:

Git GUI für das lokale Arbeiten

Es bietet sich hier die eigene App von GitHub an, zumindest was das Clonen, commiten und Auschecken von Branches angeht:

Tutorial Video

Hier gibt es mein YouTube Video in dem ich - mit einigen Schleifen - den Workflow konkret am Objekt durchgehe:

https://youtu.be/lz7l3wqo5Ds

Clone this wiki locally