Feature Branch Workflow

Feature Braches: What, Why, and When?

Feature branches are simply a branch for feature that is being actively developed but not yet merged into main. The reason for feature branches is mainly to avoid large PRs.

Generally, the decision to create a feature branch will be left to individual contributors. However, a contributor should keep the following key points in mind:

• The aim of a PR introducing a new feature is to have that feature be complete in its MVP format
• Work is still based on tickets, not complete features
• No incomplete ticket should be merged into main
• If multiple tickets should be grouped together to avoid merging incomplete features, they should be grouped together under a feature branch
• If a ticket requires a large amount of work that would result in a large PR, the ticket should be completed under a feature branch with multiple PRs made to that

Terminology: "Incomplete Feature"

We define an incomplete feature as a chunk of code that introduces impactful work that doesn't function. A great example of this is UI without logic. UI without business logic should not be merged into main, especially if it appears for users.

“feature” PR process

make sure your working branch is rebased (not merged) with main. Rebase is important here because we want to preserve commit history Spin a feature branch off main - this is now your new main branch (for this example, we’ll call it feature Make a smaller PR from workingBranch to feature ; this is what gets reviewed. There will probably be multiple PR’s here. PR names don’t need to follow PR naming guideline - they should be descriptive, however, of what they’re adding to the feature When ticket for feature is complete, then we make a PR of feature against main