Master Git Branching, Commit Standards, and Merge Strategies for Reliable Releases
This guide explains practical Git branch naming conventions, commit message formats, merging procedures, and rollback techniques to ensure smooth collaboration and stable production deployments in software projects.
Two years ago a senior developer ("T6 senior") directly committed code to the test branch, causing chaos when trying to merge into master; the incident highlighted the need for strict Git workflow rules.
1. Branch Naming
Typical branches include release, pre-release, development, and test. The main branch (master/main) is protected and only receives merges after approval.
Developers create feature branches from master, e.g., 2024/10/11/xfg-xxx, which automatically creates a folder structure for multi‑developer projects.
After local verification, feature branches are merged into test for integration testing. Bug fixes are merged back to the appropriate branch before final release.
For bug fixes, use a naming pattern like fix-username-shortdesc.
2. Commit Guidelines
Standardized commit messages simplify review, checking, and merging. Format: type:[Requirement]desc #id. Example:
feat:[Lottery Algorithm]O1, Ologn time‑complexity implementation #requirement-idReference common types: feat (new feature), fix (bug fix), docs, style, build, refactor, revert, test, perf, ci, chore.
# Main types
feat: add new feature
fix: fix bug
# Special types
docs: documentation only changes
style: formatting changes
build: build tool or dependency changes
refactor: code refactoring
revert: revert a previous commit
test: add or modify tests
perf: performance improvements
ci: CI related changes
chore: other changes (e.g., build process)3. Merging Branches
When multiple developers work on the same codebase, merging can cause conflicts. Steps:
Select the source branch to merge into test and choose “Merge into test”.
If conflicts appear, resolve them by selecting changes from left/right to the middle and click “Apply”.
After merging, run a local build and test before pushing.
4. Rolling Back Code
If a merge conflict leads to lost code, perform a rollback on the affected branch (usually test) and re‑merge after coordination with teammates.
Use a hard rollback when the test branch can be safely reset, then force‑push with:
git push origin HEAD --force5. Hands‑On Projects
The open‑source mall-swarm project (≈11K stars) provides a complete micro‑service demo built with Spring Boot 3, Docker, and Kubernetes, accompanied by a 26‑hour video tutorial covering the latest micro‑service stack and development skills.
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.
macrozheng
Dedicated to Java tech sharing and dissecting top open-source projects. Topics include Spring Boot, Spring Cloud, Docker, Kubernetes and more. Author’s GitHub project “mall” has 50K+ stars.
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.
