Skip to main content
Our main branch is main, which the live SuperOfficeDocs is built from. We use feature branches to isolate work in progress from the completed work in the main branch. Even small fixes and changes should have their own branch. This simplifies the review process and creates an accurate history of changes.
  • Create a feature branch for all new features and bug fixes.
  • Base the feature branch on the main branch.
  • Create pull requests to merge feature branches into the main branch.
  • Use lowercase letters, numbers, and hyphens only.

​
Naming conventions

  • <docs issue>-feature-name
  • <docs issue>-description
  • bugfix-description
If you haven’t already, create an issue in the appropriate repo so that you can use the issue ID in the branch name and commit messages.This convention applies to branches you create yourself. Automated branches (dependency updates, generated API/database reference syncs) follow their own naming pattern and aren’t expected to reference an issue.

​
List existing branches with Git Bash

To include remotes, add -a. To just list your remotes: git remote -v

​
Create a new local branch with Git Bash

Then:
Did you start making changes in main before making a branch? Don’t worry - git switch will bring your uncommitted changes into the new branch!
Each Git client is different, so consult the help for your preferred client.

​
Pull requests

  • main is protected: you cannot push to it directly. All changes go through a pull request.
  • At least 1 approving review from a Code Owner is required before a PR can merge. See the review process for what this means in practice.
  • All review conversations must be resolved before a PR can merge.
  • Force-pushes and branch deletion are blocked on main.
  • Code merged into the main branch should build cleanly.
  • Squash merge, so history on main stays one commit per change.
    • Exception: a PR that exists specifically to preserve multi-commit history (for example, a repo forklift that keeps per-file authorship) needs a merge commit or rebase-merge instead of squashing. Squashing would collapse exactly the history it’s meant to preserve. main requires a linear history, though, which blocks merge commits through the normal PR merge button. In practice this means a direct admin-bypass push rather than a standard PR merge.
  • End your commit message with the issue ID in parentheses, for example Fix broken link in onboarding guide (#1234). GitHub links this automatically in the PR’s commit list. On squash-merge, GitHub also appends the pull request number the same way: the two numbers are often different, and both can legitimately appear.
The live rule is under Settings > Branches on GitHub. Admin enforcement is currently off, so the one non-owner repo admin can bypass the Code Owner requirement on their own PRs. This is intentional for the pre-launch period, not permanent. Org owners of SuperOfficeDocs bypass all branch protection unconditionally, on every repo in the org. That isn’t configurable per-repo.