Committing

When to Commit

Committing should be done 'little and often'. Try to get into the habit of micro-commits - lots of small commits, rather than one large one.

Ideally each time you finish a discreet chunk of work in your feature you should commit it to the branch. This creates a history for you to step back over if necessary.

The feature does not have to be complete when you commit, nor does it necessarily have to be working - the point of feature branches is the code can be broken while you work, and it won't affect anything else.

Commits should only contain changes relevant to that chunk of work. For example if you've added a new section, don't add changes to a different section in that commit

Avoid performing one large commit for the whole feature at the end, or waiting until the end of the day before trying to split lots of work up into separate commits. This defeats the point of commits and wastes time.

If you're wondering whether it is a good time to commit, the answer is 'Yes!' It's better to commit more often than less often.

Commit Messages

All commit messages should be short but descriptive. If you find yourself writing more than one thing, then it should probably be two separate commits.

Use present tense when creating your commit messages - Create, Add, Delete etc, rather than past tense.

Describe specifically what is being done e.g. Add store switcher theme settings rather than just Add new theme settings.

Describe what you did to fix the issue, rather than what the issue was, for example Ensure push cart is above header when opened rather than Fixed push cart (not descriptive enough) or Change z-index of push cart (too code specific, why did you need to do this?)

A commit message should inform someone what was done, without them needing to actually look at the code in the commit.