Branching Guidelines

Am I looking at git history or a plate of spaghetti?

We currently follow Trunk-based development with a no-merge, no-squash, rebase-only workflow as the project is in its early stages. This essentially means you should always create a branch off main in the following format: yourname/<conventional-spec>/<issue-number>-<issue-name-kebab-cased>. For example, johndoe/feat/1-add-login-page.

Do not do git merge, as this can create a merge commit unless you fast forward; instead always pull the latest from main, check back out to your branch, then do git rebase main. This keeps a clean, linear history that is free of merge commits and easy to debug.

This is subject to change as the project and team scales. Our goal is to always keep branches as short-lived as possible, thus keeping cycle times to a minimum and reducing bugs.

Sometimes the issue names are long, in which case you can create them directly by clicking on an issue, and it'll autofill the issue number and name for you in kebab-case.

You'll often find yourself in situations where you need to work on multiple things at once, whether that be an urgent bug fix, helping someone else that's blocked, being blocked yourself, or shifting gears to a higher priority feature. Check out Git Stash for storing work in progress, and Git Worktrees for working on multiple branches at once.

If all of that sounded like giberrish to you, not to worry. Check out the Learn Git section in our knowledge base.