Git ‐ Conventional Commits (Reference)

Using conventional commits is part of coding best practices. They help standardize how we track changes to our repository. They are required to be recognized by semantic versioning and compiling our automatic changelog.

for example, a basic commit for a feature may look like this:
git commit -am "feat: Now able to self-serve ice cream."

This is a great start; however, we want to add details to these commits to further clarify and link them to their area of relevance.
Detailed conventional commits are formatted as: <tag>(<detail>): <Title>
Suitable details include: driver core plotting tests and more.

An example of how your detailed commit might look is:
git commit -am "fix(driver): Stanford830 spark_xy property incorrect return type fixed."
Be sure to include a descriptive title since titles are used to the change(s) made in this commit and included in the changelog.


For major breaking changes to pyscan (not drivers) include BREAKING CHANGE: in your commit;
however, please consult with us first since such changes may require the repository to be forked.
Breaking changes to drivers are to be incremented with their in-file version attributes.

More about breaking changes:
BREAKING CHANGE: a commit that has a footer BREAKING CHANGE: , or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.


Learn more about conventional commits here:
https://kapeli.com/cheat_sheets/Conventional_Commits.docset/Contents/Resources/Documents/index
and here:
https://www.conventionalcommits.org/en/v1.0.0/#:~:text=BREAKING%20CHANGE%3A%20a%20commit%20that,of%20commits%20of%20any%20type.

To change a past commit's message please follow the documentation for how to do this found here:
https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/changing-a-commit-message