I'll leave it up to your imagination to come up with a clever mnemonic to remember that acronym above.
I love writing about Git and SCM in general because I believe it's crucial to proper CI/CD practices. It's how we submit our code. It should matter.
I've come up with a solid metric for measuring the success and value of a commit. It has 5 key points I've mentioned above.
When did you last commit? 2 seconds ago or 2 hours ago. The longer you wait, the more trouble you will have with having your commits tell a story. How long did you wait before your last commit?
Click. That's usually the sound a camera makes when it takes a picture. That's the same idea when Git captures a diff of your changes and you put your label on it. I've found Git commit messages are oftentimes more useful than code comments. Can you describe your change verbosely, yet concisely?
Are you the type that throws everything in a laundry bin or do you sort your clothes before washing? We can relate laundry to commit messages, in a way. Your commit should only have related changes. Each commit should be easy to revert. Keep your commits small and relevant and you will never have to undo hours of work. Did you keep this commit small and only containing relevant changes, not ALL changes?
This one is super easy. Git doesn't automatically upload your commits to the "Cloud". Everything is local until you push your commits to a separate repo. Most of us humans use GitHub or something like it. Have you pushed this commit yet?
A commit is a commitment. Once it's done, do your best to avoid changing it. That means timestamps, authors, and even the contents should never change after it's saved. Is your commit a "forever commit"?
This series of posts document a high-level process to use when planning a modern web application, from project organization, collaboration considerations and tooling choices during development, all the way through deployment and performance strategies.