• All nontrivial work must happen on a branch.
• Branches should be pushed at least 1x a day for visibility, and in case your computer catches on fire.
• Branches should be as short-lived as possible, representing a single, scoped unit of work. Larger features should use feature flags to avoid becoming a long-running branch.

A branch name should have one of two prefixes, bugfix/ or feature/.

• bugfix/fix-the-thing for changes that fix a bug.
• feature/add-the-thing for all other changes.

Merge commits are fine, and we don't typically squash a branch before merging.

The exception is when we know we'll need to cherry-pick a change to another branch. In that case, we typically squash before merging so that the change can be cherry-picked quickly and cleanly.

Commit frequently, at least several times a day while you're doing active development work. Keeping commits small helps you get back to a working state more quickly if you misstep, and helps group work more atomically. It also makes it easier to isolate the change that caused a problem/introduced a behavior when using tools like git bisect and git blame.

Every commit should leave the repro in a state where it builds and, ideally, boots and runs. If you need to form temporary commits that violate this constraint (e.g. as a way of saving and pushing your work before it's done), do the following:

1. End your commit subject with (WIP) (Work In Progress) to let anyone reading the commit know that it represents unfinished work and may not compile or run correctly.
2. Consider squashing your commit with an interactive rebase (rebase -i) when you have everything working so that it's not possible to bisect onto the WIP commit.

The commit message should look like the following:

commit 769251014b5a99f9a2fabe6d8ca5943d36357ef6
Author: Jonathan McPherson <jonathan@rstudio.com>
Date:   Fri Oct 11 10:15:46 2019 -0700

Include the release name in the rstudio-server version command

The command "rstudio-server version" returns the raw major.minor.patch
version; this adds the release name to the output of the command.

Fixes #1234.

In particular:

1. The subject should be imperative; that is, it should complete the sentence "If applied this commit will..."
2. The body should contain a more detailed description of the commit, if appropriate.
3. If the commit closes (implements) or fixes an issue, the GitHub magic comments "Closes #NNNN" or "Fixes #NNNN" should be included in the body, at the end. Placing these magic comments in the subject can cause GitHub to become confused during more complicated operations.
4. The subject should be limited to 72 characters, and the body wrapped at 72 characters.

You can read more about the motivation for these rules here (but note that it's more opinionated than we are).

How to write a Git Commit Message