Pull request

Also see pull requests versus pair programming.

Commit goals

• make life easier for the reviewer
• separate refactoring from actual changes
• make it easier to undo functionality in the future by reverting a commit
• small enough number of commits to avoid heavy handed merge-time squashing
• every commit should have a reference to the business ticket being delivered
  • this provides context for when subsequent changes are made, potentially far into the future

Commit arrangement

• although in practice refactoring is done as needed, any such commits should go first
• Leytonium has tools to semi-automate rearrangement of commits