General admin content

This contains details for general administration of projects. For the most part, this document is only relevant to the team leader or if someone else has taken those admin responsibilities.

GitHub Repository Settings

  • Always protect the main branch of the repository to limit forced pushes and deletions. Within the branch protection settings, enable (check mark) these options in order to provide more security and checks to protect the main branch:
    • “Require approvals”, of at least 1 team members
    • “Dismiss stale approvals when new commits are added”
    • “Allow specified actors to bypass requirements”, the actor being the team leader
    • “Require approval of most recent reviewable push”
    • “Require status checks to pass before merging”
    • “Restrict who can push to matching branches” for the main branch

Whenever a new GitHub repo is created for a new website or software project, run our custom command from our spaid toolkit (which will need to be installed to use it) to set our custom repository settings. See that repo for more details.

Creating a GitHub repo from a local one

If a local repository exists and a GitHub repository needs to be created for that repository, run our custom command from our spaid toolkit (which will need to be installed to use it) to create the repo. See the spaid repo for more details.

Merging topic branches

Since we use SemVer and want to have a more automated release process (including automated changelogs), we need to have a clear and consistent way of merging topic branches. This way, we ensure that the changes made in each release can be easily traced.

In our repositories, we follow the GitHub flow, and to decide which kind of merge to perform on topic branches, we follow these general guidelines:

  • Squash: Atomic PRs

  • Rebase: Commits or PRs that have build and chore types as well as sync scopes (which usually fall under chore type)

  • Merge: Non-atomic/other PRs (or if the PR title starts with chore: :twisted_rightwards_arrows:)

By atomic PRs, we mean PRs that only include “self-contained changes” that are independent and fully functional on their own. E.g., a single feature and the accompanying tests or a bug fix. This way, if we accidentally introduced a bug, it would be easy to reverse that change.

Stacked PRs

The process for merging a stacked PR is:

  1. Wait until all PRs in the stack are reviewed and approved.
  2. Starting from the top of the stack, do a merge commit along with renaming the title to indicate it is a merge commit, as described above. The merge commit is used to maintain a link to the previous PR (otherwise a rebase would remove that link).
  3. Finally, squash the base PR into main.