We use Git for version control and use Conventional Commits for branch names and commit messages to enforce consistency and enjoy automatic changelog generation.
Use short and descriptive, kebab-cased names with a conventional commits type prefix separated by a slash, like so:
When several people are working on a branch, you may create personal branches that can be merged before merging the main branch to
develop. For example:
It's important for commits to follow a standard to allow efficient navigation of change history in the case of regressions and to make reviewers' lives easier.
As a general guideline, each commit should be a single logical change. Don't make several logical changes in one commit. For example, if a commit fixes a bug and optimizes the performance of a feature, split it. Here are some useful tips:
git add -p to interactively stage specific portions of modified files.
Commit early and often. Small, self-contained commits are easier to understand and revert when something goes wrong.
Order commits logically.
When working locally, it's OK if your branch history is not perfect, but that should be cleaned up before pushing upstream.
Make sure the branch you are merging is fresh by rebasing it into the target branch.
Verify that all commits adhere to this guide, otherwise, fix them.
Wait for all CI/CD processes to give the green light.