Mastering Git Branching and Commit Conventions: A Complete Guide
This guide explains Git branch naming conventions, their mapping to development environments, recommended merge workflows, standardized commit message formats, and .gitignore configuration to help teams maintain stable, well‑documented codebases.
Branch Naming
master branch
master is the main branch used for production deployment; it must remain stable. It is typically merged from release and hotfix branches and should never be modified directly.
develop branch
develop is the development branch that always contains the latest completed code and bug fixes, used for front‑back integration. New feature branches are created from develop.
feature branch
Feature branches are created from develop when developing new functionality. They should be prefixed with feature/, e.g., feature/user_module or feature/cart_module.
test branch
test is the testing environment branch, inaccessible to external users and used by testers; it is relatively stable.
release branch
release is the pre‑production branch used during UAT. It is usually merged from test or hotfix and should not be edited directly.
hotfix branch
hotfix branches are created from master to address urgent production issues; after fixing, they are merged back into both master and develop. They are prefixed with hotfix/ and follow the same naming rules as feature branches.
Branch‑Environment Mapping
Common development environments:
DEV – Development environment for developers.
FAT – Feature Acceptance Test environment for functional testing.
UAT – User Acceptance Test environment for production‑like testing.
PRO – Production environment.
Branch Merge Process
The typical lifecycle includes two main branches (master, develop) and three supporting branches (feature, release, hotfix). The diagram below illustrates the flow.
Team guidelines may include:
develop and hotfix branches must be checked out from master.
merge develop into test.
after successful functional testing, merge test into release.
after UAT approval, merge release into master.
for small tasks (<1 day), develop can be used directly; otherwise create a feature branch from develop and merge back after completion.
Git Commit Message Guidelines
Well‑written commit messages serve three purposes: speeding up code review, generating clear release notes, and helping future maintainers understand why changes were made.
Angular Git Commit Guidelines
Standard format:
<type>(<scope>): <subject>
<body>
<footer>type : the kind of change (e.g., feat, fix, docs, style, refactor, perf, test, chore).
scope : optional, the area affected.
subject : concise imperative description, no capital letter, no period.
body : detailed motivation and description.
footer : related issues or breaking changes.
Simplified Version
Many teams adopt a shorter form:
<type>(<scope>):<subject>Common Types
feat – new feature
fix – bug fix
docs – documentation only changes
style – formatting changes that do not affect code
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 or auxiliary tools
delete – remove feature or file
modify – modify functionality
build – changes to build system or dependencies
ci – continuous integration configuration
revert – revert to previous version
Single Commit Tips
Each commit should address a single category.
Do not include more than three issues in one commit.
If a commit does not follow the convention, amend it with git commit --amend -m "new message" or reset and recommit.
.gitignore Configuration
The .gitignore file lists files that should not be committed. A typical example includes:
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*
# Archives
*.jar
*.war
*.ear
*.zip
*.tar.gz
*.rar
*.cmdAdditional Recommendations
Tag each master update with a version number.
Delete feature and hotfix branches after merging to keep the repository tidy.
Commit local changes before pulling to avoid merge conflicts and potential code loss.
Signed-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.