DEV Community

Cover image for Style guide to write git history
Kaleem for This is Learning

Posted on

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).

Top comments (7)

Collapse
 
jimmymcbride profile image
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!

Collapse
 
kaleemniz profile image
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" :)

Collapse
 
feketegy profile image
George

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

Collapse
 
kaleemniz profile image
Kaleem • Edited

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.

Collapse
 
kspshnik profile image
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

Collapse
 
zack-123 profile image
Zack

Nice one! Thanks!

Collapse
 
kaleemniz profile image
Kaleem

Thank you.