git branch model

Branch Stategy

For developments/maintenances of this project, we will consider the following Git branch models.
Since this repository has been a monorepo, where the code bases of both frontend and backend exist in the same repo, we need to also utilize CI/CD pipelines with proper Git branch models.

The overview of branch models and its pipeline considerations are described in the below:

main branch

• SSoT (Single Source of Truth) of the application
• main branch has been protected for avoiding misconfigurations by unintentional git operations
• Be generally expected to be updated by merging topic branches

topic branches

• The generic branch to apply changes into main branch
• For keeping agilities by validating e2e functionalities directly accessing application (UI/APIs) themselves, we adopted to use only main branch, instead of using 2-branches model (main & develop)

releases branch

• The branch for managing releases
• Be generally expected to be updated by merging main into releases
• Typically we will not expect to update this branch directly, instead git-pr-release will generate Release PR automatically, targeted from main into releases

Considering above, the example developer workflow with Git branches will be like:

# Check current status
git status
git branch -avv

# Pull latest changes in remote, and keep your local updated
git checkout main
git fetch --all --prune
git merge

# Create branch first
git checkout -b feat/your_new_branch_name

# Do some your work: chore, feat, refactor, fix, ...etc

# Push your changes to origin
git add $SOME_FILES
git commit --message="commit message here."
git push origin feat/your_new_branch_name

# Then create PR in remote repository

branch naming conventions

prefix	stands for	example	purpose
feat/	feature	feat/add_awesome_function	Adding new features to src
sc/	sanity check	sc/verify_some_feature	Just checking some features with e2e operations
bf/	bugfix	bf/fix_some_minor_error	Fixing some errors in src

Commit message prefix rules

When you would save commit in dev environment, we could use one-line command:

git commit --message="some commit message here."

prefix	intentions
chore:	Done some work
feat:	Adding some feature
refactor:	Refactoring with src
fix:	Finalized src with design

With this prefixing rules, it requires, for example:

git commit --message="chore: Created django-app with skelton."
git commit --message="fix: Fixed typo."