docs: add more specific instructions for commits and workflow

Author: carlaKC

docs/CONTRIBUTING.md

@@ -31,7 +31,14 @@ $ make check
 
 ### Commit history
 
-- Have a clean commit history: It is preferable to use [fixup and squash](https://andrewlock.net/smoother-rebases-with-auto-squashing-git-commits/) in addressing feedback from PR review. The former (i.e. `fixup`) for the commits they apply to (during review), and latter (`squash`) once review is complete.
-- Use [good commit messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
-- Resolve all conflicts
-- Rebase often
+This project strictly adheres to an [atomic commit structure](https://en.wikipedia.org/wiki/Atomic_commit#Atomic_commit_convention). This means that:
+- Each commit should be a small, coherent logical change described with a [good commit message](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
+- Refactors, formatting changes and typo fixes should be in separate commits to logical changes
+- Every commit should compile and pass all tests so that we can use [git bisect](https://git-scm.com/docs/git-bisect) for debugging
+
+When your PR is in review, changes should be made using [fixup commits](https://andrewlock.net/smoother-rebases-with-auto-squashing-git-commits/) to maintain the structure of your commits.
+When your PR is complete, reviewers will give the instruction to `squash` the fixup commits before merge.
+
+For historical reasons, commit titles in the project are formatted as `<scope>/<type>: commit message`. A list of different commit types is available [here](https://graphite.dev/guides/git-commit-message-best-practices#2-types-of-commits).
+
+For example, a commit that refactors the `sim-cli` package will be titled: `sim-cli/refactor: {message about refactor}`.