Mastering Git Branch Naming, Workflow, and Commit Message Standards
This guide explains systematic Git branch naming, maps branches to development environments, outlines a typical merge flow, details a comprehensive commit‑message format (including Angular conventions), and provides a practical .gitignore template for clean repositories.
Branch Naming Conventions
The master branch represents the production‑ready mainline. It must remain stable and only receives merges from release and hotfix branches; direct commits to master are prohibited.
The develop branch is the integration line for completed features and bug fixes. It is used for front‑end and back‑end joint testing. New work starts from develop via feature branches.
Feature branches are created off develop and must be prefixed with feature/ followed by a concise module name, for example feature/user_module or feature/cart_module. They are merged back into develop when the feature is finished.
The test branch provides a stable environment for functional testing (FAT). It is not exposed to external users.
The release branch is used for pre‑production (UAT) testing. It is created by merging test or hotfix branches; direct modifications on release are discouraged.
Hotfix branches address urgent production bugs. They are based on master and prefixed with hotfix/. After the fix, the branch is merged into both master and develop.
Branch‑Environment Mapping
DEV – development work, typically on develop.
FAT – Feature Acceptance Test, used by testers for functional verification, mapped to test.
UAT – User Acceptance Test, final validation before production, mapped to release.
PRO – Production, live environment served by master.
Branch Merge Flow Guidelines
A typical lifecycle uses two main branches ( master, develop) and three supporting branches ( feature, release, hotfix).
Create develop and any hotfix branches from master.
Merge develop into test for functional testing.
After successful testing, merge test into release for UAT.
When UAT passes, merge release into master and tag the release.
For tasks shorter than one day, develop directly on develop; otherwise create a feature branch from develop, complete the work, and merge back into develop.
Git Commit Message Standards
A well‑structured commit message speeds up code review, produces clear release notes, and helps future maintainers understand the rationale behind changes.
Angular Git Commit Guidelines
Standard format:
type(scope): subject
body
footertype : nature of the change (e.g., feat, fix, docs).
scope : optional component or module affected.
subject : concise imperative description, lower‑case, no trailing period.
body : detailed motivation and description of the change.
footer : references to issues, breaking changes, or other metadata.
Simplified Version
type(scope):subjectCommon type Values
feat: new feature. fix: bug fix. docs: documentation only. style: formatting changes that do not affect code logic. refactor: code changes that neither fix bugs nor add features. perf: performance improvements. test: adding or correcting tests. chore: build process or auxiliary tool changes.
Additional types sometimes used: delete: removal of features or files. modify: modification of existing functionality. build: changes to build scripts or dependencies. ci: continuous‑integration configuration updates. revert: revert to a previous state.
Single‑Commit Best Practices
All changes in a commit must belong to the same category.
Limit a commit to no more than three distinct issues.
If a commit violates the format, amend it with git commit --amend -m "new message" or reset with git reset --hard HEAD and recommit.
.gitignore Configuration
The .gitignore file lists patterns for files that should not be tracked, keeping the repository clean.
Typical entries (excerpt):
# Project documentation
HELP.md
# Build output
target/
!.mvn/wrapper/maven-wrapper.jar
!**/src/main/**/target/
!**/src/test/**/target/
# IDE specific files
.idea
*.iml
.vscode/
# Logs
*.log
/logs*
# Build artifacts
*.jar
*.war
*.zipAdditional Recommendations
Tag each master update with a version number (e.g., v1.2.3) for easier management.
Delete merged feature and hotfix branches to avoid clutter.
Always push local commits before pulling to prevent merge conflicts and potential code loss.
Liangxu Linux
Liangxu, a self‑taught IT professional now working as a Linux development engineer at a Fortune 500 multinational, shares extensive Linux knowledge—fundamentals, applications, tools, plus Git, databases, Raspberry Pi, etc. (Reply “Linux” to receive essential resources.)
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.
