Branching ​

We have 3 protected branches:

• dev (our base branch)
• staging (our staging branch)
• master (our master branch)

When developing, you usually branch off dev and make PRs on dev, unless we decide as a team to kickstart a feature branch, which then will be used as the base branch.

Another exception are hotfixes, which can be branched of master directly

Naming branches

We're using the Conventional Commits standard for naming branches. Please have read through these specifications.

All branches must be connected to a story in Shortcut. Easiest is to use the Git helper in Shortcut to get a valid name for your branch. To use the git helper, open story in Shortcut and click on the branch icon.

![Alt text]("Git helpers")

The */sc-****/ in the branch name is fixed but you must add a clear and understandeable name, for example feature/sc-2355/s3-upload-for-self-serve-data-templates

Always create stories in Shortcut

We want to keep track of all the work we perform, to see progress, get better at estimating and make it easier to compile release notes. No matter how small the task you're doing, make a story in Shortcut and connect it to a branch or commit.

Commits ​

When commiting your code, your commit subject must start with one of

• fix:
• feat:
• chore:

or you won't be able to make the commit (this is validated using pre-commit hooks)

PRs ​

Run e2e tests Before creating your PR you run the e2e tests locally (we're moving this to CI but for now it's your responsibility). Do not create a PR if these tests are failing!

Creating the PR Once you're happy about your work you create a PR on the base branch (usually dev). You need to apply one of the PR templates, the default one is for dev, but staging and master PRs have different templates.

You then request at least one person to review your PR. As a rule, we want everyone to review code from time to time, so make sure to switch your approver now and then and do not invite the whole dev team. Also keep in mind that it doesn't make much sense for a backend developer to review a frontend PR.

Upon creating the PR, the integration tests run in CI. Your PR can only be merged if those tests pass, so please keep an eye on the pipeline passing.

Notify the team Once you've created your pr, you post it to the #dev Slack channel as follows

pr: [link to pr] @reviewer

pr: [link to pr] @reviewer

Everyone from the dev team, especially the people you request review from, is then notified that your PR is ready.

In case you're requested to review, you respond to the message in Slack with one of these icons 💬  - there are comments that the developer needs to address. ✅  - the pr is approved for merging

You merge it Once all issues are resolved and your PR is approved, and tests are passing, you merge it. You then also move the card in Shortcut to the respective column and tag respective people to test your PR.

IMPORTANT: Keep PRS small We love small PRs so it's easy to review code and keep track of changes. As a rule of thumb make sure to keep your PRs small. As a rule of thumb make sure to keep your PRs narrow and specific, consider splitting new atomic components into their own PR away from a new feature for example.