A new perspective

Core concept: Issue branch

We work issue branches defined as follows:

• Must come off of main
• Must have the issue number it relates to as the first part of the name followed by a dash and then the title of the issue (whitespaces replaced by underscores)

gitGraph
    commit id: '34'
    commit id: '56'
    branch "32-issue"
    checkout "32-issue"
    commit id: 'a'

Workon

When an issue is worked on

• An existing branch that matches the definition of an issue branch must be reused if it exists either locally or remote
• or else it is created
• Must be registered with the issue as a development branch (gh issue develop ...) (implies being made made available to origin immediately upon creation)
• Must have it’s upstream set to a branch with the same name in origin

If the repo is connected to a kanban board:

• The issue must be added to the project if it isn’t already
• The issue must be updated to status ‘work in progress’
• The person who began working on the issue must be assigned to the issue

During development the developer can share the branch with co-workers (workon, pull, push) and create as many commits as desired

gitGraph
    commit id: '34'
    commit id: '56'
    branch "32-issue"
    checkout "32-issue"
    commit id: 'a'
    commit id: 'b'
    commit id: 'c'