Fundamentals 9 min read

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.

Liangxu Linux
Liangxu Linux
Liangxu Linux
Mastering Git Branch Naming, Workflow, and Commit Message Standards

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

footer

type : 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):subject

Common 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
*.zip

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

Branch lifecycle diagram
Branch lifecycle diagram
workflowGitcommit messagebranchinggitignoreversion-control
Liangxu Linux
Written by

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

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.