Commit Guidelines

This page is a work in progress. Some quick notes:

• If you find yourself saying "and" a lot, maybe split that commit into two?
• The app should be in a working state before and after each commit.
  Example: If you are adding in a new feature and have a commit for the backend and a commit for the frontend, the backend commit should be first.
• Make sure you have meaningful commits and informative commit messages

Wait so I've already committed. Are you asking me to edit my commit?

• I understand that normally people tell you that editing commits is bad.
  It's true to this extent: In general, editing commits is bad.
• Commits that you should not be editing:
  • Commits on master -- master serves as a permanent history of the app.
  • In general, other people's commits.
• It's okay to edit commits that you haven't pushed. Just make sure that (1) either your changes are small enough that you don't mind doing them again, or (2) you know how to undo or restore your steps in case something goes wrong.
• Editing commits is tricky if you haven't done it before but it can be really easy with maybe 5 minutes of guidance

Commit message guidelines from the Git book:

Short (50 chars or less) summary of changes

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 an email 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); tools like rebase can get confused if you run
the two together.

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