Controlling version control.
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 -pto 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.