Karvin Ong

Let’s talk

,

A Git workflow for teams that look after many codebases

When one team looks after dozens of client codebases, a consistent Git workflow isn’t bureaucracy. It’s how you answer “what changed, when, and why?” in minutes instead of hours. These are the rules I’ve found make the biggest difference.

1. Name branches after the ticket, and only the ticket

feature/SHOP-142
hotfix/SHOP-150
epic/SHOP-100

No descriptive suffixes, no “-v2”, no second branch for the same ticket. The ticket holds the description, discussion and approvals; the branch name only needs to point to it. It also makes branches easy to find and impossible to duplicate.

2. Put the ticket key in every commit message

SHOP-142 reset last sync marker when a batch fails

Months later, git log or git blame on any line leads straight back to why it was written. Jira and Bitbucket also link the two automatically.

3. Separate support work from project work

  • Support fixes branch from the production branch, so they can be released on their own, quickly.
  • Project work collects on an epic/ branch until the whole feature is ready.

Without this, an urgent fix gets stuck behind half-finished project code, or worse, ships with it.

4. Change staging and production only through pull requests

No direct pushes. Every change is reviewed, meets the coding standard before the pull request is opened, and leaves a record of who approved it.

5. Name releases after a release ticket, not a date

release/SHOP-160

Date-based names look tidy but fall apart in practice: there can be more than one release a day, a date says nothing about what was included, and it’s hard to audit or to know who signed off. A release ticket lists the tickets included, the deployment steps, the approvals and the result.

6. Keep branches fresh and test your own work

  • Sync with the production branch before creating a branch, and rebase long-lived branches regularly.
  • Test your own change on staging before handing it over.
  • Record any configuration or admin changes on the ticket. Code is in Git; configuration changes are easy to forget.

The point

None of these rules is clever. Their value is that everyone follows them on every project, so any developer can open any repository and understand its history immediately.