Git Branch Management and Commit Message Guidelines
This article outlines best practices for Git branch management—including naming conventions for master, develop, feature, release, and hotfix branches—and provides detailed commit message guidelines based on the Angular style, complete with example commands and formatting rules to improve workflow and code traceability.
Git Branch Management
Git is the most widely used source-code management tool. To keep development standardized, maintain clear commit history and branch structure, this guide defines the recommended Git operations.
Branch Naming
master branch
The master branch is the main branch used for deploying to production; its stability must be ensured and it should never be modified directly.
develop branch
The develop branch holds the latest code after feature integration and bug fixes.
feature branch
Feature branches are created from develop for new functionality. Naming convention: feature/ followed by a descriptive name, e.g., feature/user_module or feature/cart_module .
release branch
Release branches are used for pre-production testing. When a set of features is complete, they are merged into develop, then a release branch is created for testing. Bugs found during testing are fixed directly on the release branch, which is later merged into both master and develop.
hotfix branch
Hotfix branches address urgent production issues. They are created from master, fixed, then merged back into both master and develop to keep all branches up-to-date.
Common Tasks
Add New Feature
(dev)$: git checkout -b feature/xxx # create feature branch from dev
(feature/xxx)$: blabla # develop
(feature/xxx)$: git add xxx
(feature/xxx)$: git commit -m 'commit comment'
(dev)$: git merge feature/xxx --no-ff # merge feature into devFix Urgent Bug
(master)$: git checkout -b hotfix/xxx # create hotfix branch from master
(hotfix/xxx)$: blabla # develop fix
(hotfix/xxx)$: git add xxx
(hotfix/xxx)$: git commit -m 'commit comment'
(master)$: git merge hotfix/xxx --no-ff # merge into master and deploy
(dev)$: git merge hotfix/xxx --no-ff # merge into develop to syncTesting Environment Code
(release)$: git merge dev --no-ff # merge develop into release for testingProduction Deployment
(master)$: git merge release --no-ff # merge tested release into master
(master)$: git tag -a v0.1 -m 'deployment version' # create a tagCommit Message Guidelines
Consistent commit messages speed up code review, help generate release notes, and make it easier for future maintainers to understand why changes were made.
The Angular Git Commit Guidelines are widely adopted. The format is:
<type>: <subject>
<body>
<footer>Where:
type : the nature of the change (e.g., feat , fix , docs , style , refactor , perf , test , chore ).
scope : optional area affected by the change.
subject : a concise imperative description, no capital letter, no trailing period.
body : detailed explanation of the change, motivations, and implementation details; use line breaks or | for wrapping.
footer : references to related issues or breaking changes.
Commit message requirements:
# Title line: ≤50 characters, summarizing the change
#
# Body: detailed description, ≤72 characters per line
# * Why is this change needed? (bug fix, new feature, performance, etc.)
# * How does it solve the problem? Steps taken
# * Any side effects or risks?
#
# Optionally add a link to an issue or documentationReference Links
http://www.ruanyifeng.com/blog/2012/07/git.html http://ivweb.io/topic/58abda9d2117ae2f4995b4a8 https://segmentfault.com/a/1190000009048911
Architect's Tech Stack
Java backend, microservices, distributed systems, containerized programming, and more.
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.