Git

Workflow

Our workflow is inspired by the git workflow popularized by GitHub. But there are a few differences.

While we frequenty use Pull Requests to solicit code reviews and initiate discussions, some teams prefer to discuss and review code with Hipchat, screensharing, etc. We like the flexibility of leaving the specifics up to the team.

We don’t generally deploy our feature branches to production. We merge into master first. The master branch is what’s in production.

Commit messages

A commit message should be approached like an email that is written for the current and future development team: the attachment is the source code, the first line of the commit message is the subject, and the rest of the commit message is the body of the email.

Here’s an example of a good commit message:

The first line describes what the commit does and why

If there are further details in the commit, there is a blank line
between the "subject" line and the "body".

Use imperative present tense: "Fix bug", not "Fixed bug" or "Fixes bug."

Use a maximum of 72 characters per line, when possible.

If the commit is associated with a Pivotal Tracker ticket, include the
[#ticketid] somewhere so it will appear in the ticket.

Archive names

Git repos should use an _ (underscore) in there names in lieu of sapces (not -). Preferablly repos are one word.

Branch names

Use - (hyphen) in branch names. Never use _ (underscore). - is faster to type, and consistency is valuable.

Resources

Tools

Git hook tools are recommended to avoid common mistakes:

  • pre-commit automatically runs our static analysis tools on any changed files you commit. This is recommended because it prevents CI from breaking when it runs those same static analysis tools.
  • Fit Commit validates commit messages.