Committing Change

Here we'll cover the best practice of commits

Making the commit#

There are 6 steps to committing change for review

# 
> git checkout -b <branchname>
/// make change
/// update and run tests locally 
> git add <changedfile.code>
> git commit
> git push --set-upstream origin <branchname>

The seven rules of a great Git commit message#

We like the seven rules that have been written before:

1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how

Read the full article on writing the perfect git commit message

An Example#

  Summarize changes in around 50 characters or less

  More detailed explanatory text, if necessary. Wrap it to about 72
  characters or so. In some contexts, the first line is treated as the
  subject of the commit and the rest of the text as the body. The
  blank line separating the summary from the body is critical (unless
  you omit the body entirely); various tools like `log`, `shortlog`
  and `rebase` can get confused if you run the two together.

  Explain the problem that this commit is solving. Focus on why you
  are making this change as opposed to how (the code explains that).
  Are there side effects or other less intuitive consequences of this
  change? Here's the place to explain them.

  Further paragraphs come after blank lines.

   - Bullet points are okay, too

   - Typically a hyphen or asterisk is used for the bullet, preceded
     by a single space, with blank lines in between, but conventions
     vary here

  If you use an issue tracker, put references to them at the bottom,
  like this:

  Resolves: #123
  See also: #456, #789

Ensure you have the latest code from master

The Process#

Branching#

> git checkout -b <branchname>

Add changes#

> git status

> git add <changedfile.code>

Commit#

Then run

> git commit

and complete your commit message

Push to remote branch for review#

> git push --set-upstream origin <branchname> 
# bash alias can be used to speed this up
# gitp='git push --set-upstream origin $(git rev-parse --abbrev-ref HEAD)'

Is it time for a PR?#

We like to make commits often, working in small batches, testing and consulting with our team regularly. We don’t like to flood the team with PRs, and instead will often raise a PR to aggregate many commits when customer value has been realized.

A good PR should encapsulate work which can be released to the customer as is.

Raising a PR