Master Git Branching, Commit Standards, and Merge Strategies for Reliable Releases

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-id

Reference common types:

feat

(new feature),

fix

(bug fix),

docs

,

style

,

build

,

refactor

,

revert

,

test

,

perf

,

ci

,

chore

.

<code># 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)
</code>

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 --force

5. 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.