Style guide to write git history

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 section instead of feat: 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-1 for commits use ":" colon notation e.g chore: rename product rental file.

• Utilize squash merges whenever appropriate (combines all commits into a single commit upon merging).

Comments

[Jimmy McBride]

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!

[Kaleem]

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" :)

[George]

I just use "final final - updates made to files"

[Kaleem]

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.

[Zack]

Nice one! Thanks!

[Kaleem]

Thank you.

[Evgeny Karpel]

I also use [Setup] for scaffolding stuff or setup files, and [Final] to PR "production-ready" (in some, probably limited, sence) code from dev to master