Git
Controlling version control.
Last updated
Controlling version control.
Last updated
We use Git for version control and use 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:
feat/implement-arbitrator
fix/invalid-rulings-from-arbitrator
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:
feat/implement-arbitrator/alice
feat/implement-arbitrator/bob
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:
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.
Branches that are used by CI/CD processes, like develop
and master
should never have their history rewritten.
Before merging:
Test before you push. Do not push half-done work.
Keep repos in good shape by performing maintenance tasks from time to time:
git-gc
git-prune
git-fsck
Follow . If the repo uses , you can just run yarn run cz
and follow the prompts to craft a valid message.