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:
Always delete merged branches, locally and remotely. You can use the following command to list them, git branch --merged | grep -v "\*".
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.
When to Commit
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:
Use 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.