chore: prepare the repo for trunk-based development
helmturner opened this issue · 2 comments
I've been thinking about ways to make the contributor experience more efficient and enjoyable, and I think branch-based development would be go a long way toward that goal.
We already throw out many of our own branching conventions to facilitate a better pace during Hack Nights, so @zenlex and I came to the conclusion that it doesn't really make sense to heighten those requirements for async work. Given that contributors already have to fork the repo, and deployment isn't necessarily tied to branching, it makes sense to just stop using branches as a form of GH repo management. The goal, then, is to have just 1 branch: main. Everyone forks, and PRs, to main.
This will require some changes in the contributor flow to work, though. The new guidance will be based around these principles:
- Contributors will first fork the repo, then immediately create a Draft PR to
main - Conventional Commits are enforced before merging (this can be done by repo maintainers in code review)
- Commit messages will now be the primary and only way of communicating what, and why, changes were made
- PRs may be merged at any point — even if it's an incomplete feature, or one that fails CI
- CI will now happen on merge, not on PR. Failing pulls will be reverted. Merges should be small and frequent
- When merging PRs to main, they should always be squashed but keep the commit notes
- Friction for creating PRs should be near 0 — meaning no more PR template requirements, no descriptions, no descriptive title names—just something generic. There may be conventions set for this. Discussions will still occur in PRs, but will not be tied specifically to a given feature, bug, etc.
- Deployment will now occur when a tag is created for a release candidate and pushed
Steps to implement:
- change deploy trigger to tag instead of branch in the GH action
- merge dev into main
- kill all the branches
- update contributing doc
- update/remove PR template
@CKCarr @deino475
This change is sure to have a big impact not only on contributors, but on current and future maintainers. Any thoughts on all this?
@helmturner FYI I renamed prod to main to get away from associating the branch with a deployment and to follow your description above. Otherwise I think this is good!