When you commit a change in git, you are assigning a change to a message. The change is controlled when you add the files into the commit, but the message is the only bit that can’t be automated.
The easiest way to write a good commit message is to say why the code is changing.
The change :
commit fb8717c3
Author: Andy Callaghan <[email protected]>
Date: Wed Mar 6 11:41:39 2019 +0000
Updated Readme following Alina’s review
The tmp/dump.sql file was ambiguous as to where to place it, so made it clearer.
commit fb8717c3
Author: Andy Callaghan <[email protected]>
Date: Wed Mar 6 11:41:39 2019 +0000
Updated Readme
Keep commits small and atomic. They should represent the smallest change that can be grouped together.
* c9679ddc (HEAD -> fix-admin-spec-examples) Tidy up whitespace
* 279a6efb Wrap the example with time cop block
* 9112118d Make admin spec - assert an admin model is created
For instance in the example above - the Tidy up whitespace
commit is seperated from the functional commits. It’s important to do the tidying, but having it cloud up other commits with functional changes, especially if they’re across multiple files will make your job hard later.
By keeping commits smaller, and more descriptive, we document the code changes properly. This makes changes to these files easier in the future, and it becomes a layer of documentation that will be invaluable.
Now we’ve seen how to write a good commit message, we can read about cherry picking commits