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

Please also refer Deployment & Pipelines sections for what actions/jobs will be triggered in the changes of each branch.

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

Naming conventions

For better visibility and effective change managements, generally we will align conventional-commits specs in the name of both each commit and branch.

Commit messages

prefix	intentions
chore:	Done some work, mainly not related to code basis
feat:	Adding some feature
refactor:	Refactoring with src
fix:	Finalized src with design
ci:	Changes related to CI/CD pipelines

When you would save your changes as commits, we could use one-line command git commit --message="...", with this prefixing rules, it requires, for example:

git commit --message="chore: Created django-app with skelton."
git commit --message="fix: typo in functions()."

In case you need to update the commit messages, which has been already committed:

git commit --amend --message="fix: typo"

# if you have already pushed the changes to remotes (note that this will change histories in remote)
git checkout ${your_branch}
git push -f origin ${your_branch}

Topic branches

Same as commit messages, the name of topic branches will also be expected to follow the conventional-commits spec, and the short descriptions of each topic branch should be followed kebab-cases.
For example:

prefix	stands for	example	purpose
feat/	feature	feat/add-awesome-function	Adding new features to src
docs/	documentations	docs/updated-usage-section	Updated specific sections in README.md
fix/	bugfix	fix/some-minor-error	Fixing some errors in src

Please not that the name of topic branch will be used for PR Labeler, so that the PR labels will be depended on name of branch, which you created in local environment and pushed into remotes.

Pull Requests/Issues

Same as branch names and commit messages, we will expect that PR/Issue title would also align the conventional-commits specs. For example:

ci: review release CI triggers and Git branch model

For validating PR titles, we use GitHub Apps called Semantic PRs.
The allowed prefix categories are defined in its configs (.github/semantic.yml), and please visit the sources for more details.

For validating Issue titles, we use custom GitHub Actions hwakabh/semantic-issue-action.
This action will check issue title is aligned conventional-commits spec or not, when the issue would be opened/updated.
Please see the sources for more details.