Version Control - Commit Hash - Content Versioning

Hash

Given a digital asset (source code, binaries, groups of files, images, videos, etc.), run a cryptographically-secure hash over the bits that comprise that asset, and use the hash as the version for that asset.

See http://conver.io/

Example in Git:

git checkout 72e5e550d1835013832f64597cb1368b7155bd53

where 72e5e550d1835013832f64597cb1368b7155bd53 is the content hash.

Message

A clean, clear consistent commit log is an indication of a high-quality project.

It's also a great tool for users and maintainers alike as the commit log becomes the release notes, which is the main way that people find out what features are in the project.

• The first line of the commit message must be a concise and useful description of the change.
• Prefix with case Id in brackets, if the change is not trivial. Create a case if necessary.
• The message is often, but not always, the same as the case subject.
• Start with a capital letter.
• Do not finish with a period.
• Use imperative mood (“Add a handler …”) rather than past tense (“Added a handler …”) or present tense (“Adds a handler …”).
• If possible, describe the user-visible behavior that you changed (“FooCommand now creates directory if it does not exist”), rather than the implementation (“Add handler for FileNotFound”).
• If you are fixing what is clearly a bug, it is sufficient to describe the bug (“NullPointerException if user is unknown”) and people will correctly surmise that the purpose of your change is to fix the bug.
• If the contributor is not a committer, add their name in parentheses at the end of the message.
• Read the messages of previous commits, and follow their style.

Inspired by Julian Hyde email on the Calcite mailing list (Check those commit messages please! at 1 June 2018 at 19:42)