Git Practices/Rule

1. Workflow
Roughly, below are the steps to follow. Read the links below to understand details:
i) fork the repo to your account (use the fork button on top right)
ii) clone forked repo to your local
iii) create a feature branch and work in it
iv) push the branch to your remote fork (before pushing, merge master once again to make sure any fresh changes of other contributors
are included)
v) raise a PR from the branch on your fork to main Dehaat fork
To understand the core idea, read these - Forking + Feature branch
2. A PR can only be merged after at least one approving review.
3. For merging, use rebase instead of creating merge commits. Read merging vs rebasing. This avoids creating unnecessary commits.
4. Squash multiple git commits to keep only meaningful ones before raising PR. Bookmark this, you will need it.

Write appropriate git commit messages

Format: < type > < subject >< jira-id >

Commit < types >:

IMP : (new feature, better way of doing something)

FIX : (bug fix)
HOT_FIX : (a pressing bug fix)
DOC : (changes/improvement to the documentation)
REF : (formatting, etc.)

DCL : (data clean up, data migration, etc.)

REM : (code removal)

The seven rules of a great Git commit message

Separate subject from body with a blank line

Limit the subject line to 50 characters
Capitalize the subject line
Do not end the subject line with a period
Use the imperative mood in the subject line
Wrap the body at 72 characters
Use the body to explain what and why vs. how

Example

1 [IMP] Add credit note category model (CF-392)

2 ^--^ ^------------^
3 | |
4 | +-> Summary in present tense.
5 |
6 +-------> Type

References:

How to Write a Git Commit Message

https://www.conventionalcommits.org/
Semantic Commit Messages
Karma - Git Commit Msg