When creating a new project and working on a team, you’ll likely want to improve collaboration. That way, your team members can make meaningful contributions to the code base simultaneously rather than step on each other’s toes. Implementing developer norms about GitHub is essential to establish early on to encourage consistency, readability, and code quality.

1. GitHub Actions for Quality Checks

Here’s an important and easy way to ensure developers are pushing working code: implement static analysis as Github Actions on your code. This ensures a common source of truth for whether or not code meets a “standard” before merging it in. Within Github, you can prevent developers from merging unless all these checks have passed. Having a simple check on currently running tests, linting, and formatting that may be forgotten in efforts to review the feature work being pushed also lowers the burden on other team members.

2. Squash Merges

Squash merges allow the main branch to maintain readable commits about the feature work that was merged in. Oftentimes, feature branches have lots of work-in-progress (WIP) commits that don’t give other team members meaningful information about what was done. This pollutes the commit history of the main branch and makes it less useful.

3. Require PR To Merge to Main

There might be exceptions to this, especially at the beginning of the project when you are doing setup. However, once you start your first sprint of feature work, changes to the repo should require a pull request to allow for code review and record-keeping. Additionally, this enforces code quality through peer code review and Github action checks you set up if you followed suggestion one.

4. Automatically Delete Head Branches

Once branches are merged into the main, why do you need them? Sometimes it’s helpful to maintain a history of the commits on the branch for future maintenance or bug fixes. However, if this work is merged into main, there’s no need to keep it. That’s because you can always restore branches on closed pull requests (assuming you’re doing pull requests). The commit history on main should be enough if you need to check out any previously-merged branch. This allows a clutter-free branch list that only shows what you’re currently working on.

These suggestions are truly preferences, and everyone has a level of control they are comfortable with. Sometimes it’s not necessary to restrict the repository in such a way for these practices to be followed. However, it can be a great way to incorporate best practices built into your project early on and get everyone on the same page.