Master Git Branching and Commit Standards for Stable Development
This guide explains Git branch naming conventions, their correspondence to development environments, recommended merge workflows, standardized commit message formats—including Angular guidelines and a simplified version—and provides a practical .gitignore template, helping teams maintain stable codebases and efficient collaboration.
Branch Naming
master branch
master is the main branch used for production deployment; it must remain stable and is typically merged from release and hotfix branches. Direct modifications are prohibited.
develop branch
develop is the development environment branch, always containing the latest completed and bug‑fixed code, used for front‑back integration. Feature branches are created from develop.
feature branch
Created from develop for new features. Naming starts with feature/ followed by the module name, e.g., feature/user_module or feature/cart_module.
test branch
Test environment branch, not accessible to external users, used by testers; it is relatively stable.
release branch
Pre‑release (UAT) branch used during the UAT testing phase; usually merged from test or hotfix branches, and direct modifications are discouraged.
hotfix branch
Created from master to address urgent production issues. After fixing, merge back to both master and develop. Naming starts with hotfix/ and follows the same pattern as feature branches.
Branch‑Environment Mapping
Common environments used in system development:
DEV (Development) – used by developers for debugging.
FAT (Feature Acceptance Test) – functional acceptance testing environment.
UAT (User Acceptance Test) – user acceptance testing environment.
PRO (Production) – live production environment.
Correspondence between branches and environments:
master – PRO – accessible.
develop – DEV – accessible.
feature – (no specific environment) – not accessible.
test – FAT – accessible.
release – UAT – accessible.
hotfix – (no specific environment) – not accessible.
Branch Merge Process Guidelines
The typical lifecycle involves two main branches (master, develop) and three auxiliary branches (feature, release, hotfix). The diagram below illustrates this flow.
Example team process:
develop and hotfix branches must be checked out from master.
merge develop into test.
after successful functional testing, merge test into release.
once UAT passes, merge release into master.
for small tasks (<1 day), develop directly; otherwise create a feature branch from develop, then merge back.
Git Commit Message Guidelines
Well‑structured commit messages accelerate code review, improve release notes, and help future maintainers understand changes.
Angular Git Commit Guidelines
type(scope): subject
<body>
<footer>Components:
type : commit type.
scope : optional, the area affected.
subject : concise imperative description, no capital letter at start, no trailing punctuation.
body : detailed explanation of the change and motivation.
footer : references to related issues or breaking changes.
Simple Version
type(scope):subjecttype Definitions
Recommended types from Angular guidelines:
feat – new feature
fix – bug fix
docs – documentation only
style – code style changes (whitespace, formatting, missing semicolons, etc.)
refactor – code changes that neither fix a bug nor add a feature
perf – performance improvements
test – adding or correcting tests
chore – changes to build process, auxiliary tools, or libraries
Additional common types:
delete – remove feature or file
modify – modify feature
build – changes to the build system or dependencies (e.g., webpack, gulp, npm)
ci – continuous integration configuration changes
revert – revert to a previous version
Single Commit Tips
All changes in a commit must belong to the same category.
Limit a commit to at most three distinct issues.
If a commit does not meet the guidelines, amend it with git commit --amend -m "new message" or reset and recommit using git reset --hard HEAD.
.gitignore Configuration
The .gitignore file lists patterns for files that should be ignored by Git, helping keep the repository clean.
Typical example:
HELP.md
target/
!.mvn/wrapper/maven-wrapper.jar
!**/src/main/**/target/
!**/src/test/**/target/
### STS ###
.apt_generated
.classpath
.factorypath
.project
.settings
.springBeans
.sts4-cache
### IntelliJ IDEA ###
.idea
*.iws
*.iml
*.ipr
### NetBeans ###
/nbproject/private/
/nbbuild/
/dist/
/nbdist/
/.nb-gradle/
build/
!**/src/main/**/build/
!**/src/test/**/build/
### VS Code ###
.vscode/
# Log files
*.log
/logs*
# BlueJ files
*.ctxt
# Mobile Tools for Java (J2ME)
.mtj.tmp/
# Package files
*.jar
*.war
*.ear
*.zip
*.tar.gz
*.rar
*.cmdSigned-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Su San Talks Tech
Su San, former staff at several leading tech companies, is a top creator on Juejin and a premium creator on CSDN, and runs the free coding practice site www.susan.net.cn.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.