A simple style guide to write maintainable git history.
Commits guide
Feat
Use the feat prefix for feature-related changes.
feat: add support for purchase order
Chore
Use the chore prefix for non-feature-related changes.
chore: rename product rental file
Refactor
Use the refactor prefix for refactoring changes.
refactor: file improvements for product rent section
Deploy
Use the deploy prefix for deployment-related changes.
deploy: trigger deployment
Docs
Use the docs prefix for documentation-related changes.
docs: update starting guide
Fix
Use the fix prefix for bug fixes or error corrections.
fix: resolve issue with user a glitching on login
Branches guide
For large features, divide your branch into smaller modules and use suffixes to continue changes.
feat/product-purchase-1
feat/product-purchase-2
feat/product-purchase-3
feat/product-purchase-4
If product purchase is a big module then you can use suffix numbers.
You will make changes in product-purchase-1, merge it in the major branch, and then start with product-purchase-2 from the major branch.
General guide
Create PRs for your changes; do not push directly to the major branch.
Be consistent with your approach of naming branches and commits.
Use present tense for commit messages:
feat: add products for rental sectioninstead offeat: added products for rental section.In your PR, each commit should relate to an specific change, rather than combining multiple changes into one large commit.
For branches, use "/" slash notation e.g
feat/product-purchase-1for commits use ":" colon notation e.gchore: rename product rental file.Utilize squash merges whenever appropriate (combines all commits into a single commit upon merging).
Top comments (7)
What about doing every commit as "init commit"? ;P Just kidding! I really liked this article, and some of these rules I already follow, but not others. I think I'm going to make these rules standard in my gitflow now. Thanks for the great article!
I am glad you found it helpful. Using the guide I am sure you will find your way out with your specific needs/changes, add a thing or two, that is the point of it, keeping it simple is key when creating a guide, a guide not containing "everything" :)
I just use "final final - updates made to files"
I think "final final - updates made to files" could work let's say fixing a bug you attempt with unstructured commits and when you are done do a squash merge.
I also use [Setup] for scaffolding stuff or setup files, and [Final] to PR "production-ready" (in some, probably limited, sence) code from
devtomasterNice one! Thanks!
Thank you.