Branch pro Ticket: So wissen Sie immer, wo der Code liegt
Ein Bug taucht wieder auf, und niemand weiß mehr, in welchem Branch der Fix war. Ein Kunde fragt, ob sein Wunsch schon live ist, und Sie suchen zehn Minuten in Git. Mit ein paar festen Absprachen zu Branches und Commits gehört das der Vergangenheit an. So richten Sie es ein.
1.Ein Ticket, ein Branch
Beginnen Sie jede Arbeit mit einem Ticket. Ist die Arbeit zu groß für einen Branch, ist das Ticket zu groß: Teilen Sie es in Unteraufgaben mit jeweils eigener Nummer auf. So bleibt ein Pull Request klein genug für ein gründliches Review.
2.Die Ticketnummer im Branch-Namen
Vereinbaren Sie ein festes Format, etwa feature/ASUP-12-kurze-beschreibung oder fix/ASUP-14-ideal-callback. Das Präfix sagt, um welche Art von Arbeit es geht, die Nummer, zu welchem Ticket sie gehört. Tools, die die Nummer erkennen, können den Branch dann automatisch verknüpfen.
3.Die Nummer in jedem Commit
Setzen Sie die Ticketnummer an den Anfang Ihrer Commit-Nachricht: ASUP-12 Login-Formular validieren. Auch wenn ein Commit später in einem anderen Branch landet, sehen Sie, zu welchem Ticket er gehört. Mit Smart Commits aktualisieren Sie das Ticket gleich mit, zum Beispiel mit #time 45m oder #review.
4.Pull Requests aktualisieren das Ticket
Lassen Sie einen geöffneten Pull Request das Ticket auf In Review setzen und einen Merge den Branch auf gemergt. Dann stimmt der Status auf dem Board, ohne dass jemand daran denken muss.
5.Prüfen Sie es im Review
Nehmen Sie in Ihre Review-Regeln auf, dass die Ticketnummer im Branch und in den Commits steht. Ein Pull Request ohne Ticket geht zurück. Nach ein paar Wochen macht es jeder von selbst.
Zusammengefasst
- Ein Ticket, ein Branch
- Die Ticketnummer im Branch-Namen
- Die Nummer in jedem Commit
- Pull Requests aktualisieren das Ticket
- Prüfen Sie es im Review