Feature Branch Workflow

Feature Branches: 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 Branch Process

For this example, we will use working for the branch in which your code changes exist, feature as the feature branch, and main as Mozilla Firefox iOSs main branch.

Feature branch spinoff process:

• If you're starting work on a ticket and know that it requires a feature branch
  • create a feature branch off main, and then make a working branch off feature
• If you already have a working branch and realize it should be a feature branch
  • make sure your working branch up to date with main either through a rebase or a merge. This is to prevent conflicts down the line
  • create a feature branch off main

In either case, both feature and working branches should be pushed to your fork.

Feature Based Pull Requests

working PRs

• All working branches that are ready for review should make a PR against feature
• Request the appropriate reviewers
• Once a PR is approved, you may merge it and continue working

feature PRs

• Once all work on a feature branch is complete and ready for main, make a PR for feature from your fork to main
• PR's name should follow PR Naming Guide
• PR's description should include an explanation of the feature
• Only tag reviewers that have already reviewed the PRs of that branch
  • They will automatically approve the PR as it's assumed that everything in the feature branch will have already been reviewed
• Once BR and other tests pass, you may merge the branch