跪拜 Guibai
← Back to the summary

The Git Workflow Rules That Keep Hundreds of Devs From Breaking Production

Foreword

Recently, a community member asked: "Brother San, do you have a good Git specification you can share for reference?"

In this article, I'll break down the Git specifications used by top-tier tech companies from start to finish.

I hope it helps you.

For more project-based practices, visit the Java Commando Network: susan.net.cn/project

1. Why Do Big Tech Companies Value Git Specifications So Much?

Before discussing specific specifications, let's first understand a fundamental question—why do big tech companies consider Git specifications so important?

First reason: Scale.

A single project in a big tech company might have dozens or even hundreds of developers modifying code simultaneously.

Without specifications, issues like branch conflicts, code overwrites, and version chaos can overwhelm a team like an avalanche.

Second reason: Traceability.

When a bug appears online, you need to quickly locate who changed it, when they changed it, and what they changed.

If the commit message is a mess, troubleshooting is like looking for a needle in a haystack.

Third reason: Automation.

The CI/CD pipelines of big tech companies heavily depend on Git specifications—automatically generating changelogs from commit messages, triggering deployments to corresponding environments from branch names, and determining version numbers from tags.

Whether the specification is well-written directly determines whether the pipeline can run.

To put it bluntly, specifications are not for "managing people," but for "saving trouble."

2. What Models Do Big Tech Companies Use?

Branching strategy is the "skeleton" of Git specifications.

Currently, there are three mainstream branching models in big tech companies:

2.1 Git Flow: The Most Classic Enterprise Model

Git Flow is a branching model proposed by Vincent Driessen in 2010 and remains a standard practice in many big tech companies today.

It defines two types of long-term branches and three types of short-term branches.

Two Long-Term Branches (Permanent):

Three Short-Term Branches:

Core Flow Diagram of Git Flow:

image.png

Applicable Scenarios: Large projects with explicit version release plans, software requiring simultaneous maintenance of multiple versions.

2.2 GitHub Flow: Lighter and More Agile

GitHub Flow is the workflow officially recommended by GitHub, much simpler than Git Flow.

The core has only one long-term branch, main, with all development occurring on short-term feature branches.

Core Process:

  1. Create a feature branch from main
  2. Develop and commit on the feature branch
  3. Create a Pull Request
  4. Merge into main after code review approval
  5. Deploy immediately after merging

Core Flow Diagram of GitHub Flow:

image.png

Applicable Scenarios: Projects requiring continuous delivery and rapid iteration. Google internally adopts similar strategies extensively.

2.3 Trunk-Based Development

Trunk-Based Development is a strategy advocated by big tech companies like Google.

Core concept: All developers work on the trunk (trunk/main), making changes through short-lived feature branches.

Key Rules:

Core Flow Diagram of Trunk-Based Development:

image.png

Applicable Scenarios: Internet products requiring extreme iteration speed, teams with high DevOps maturity.

2.4 How to Choose Among the Three Models?

Comparison Dimension Git Flow GitHub Flow Trunk-Based
Complexity High Low Medium
Suitable Team Size Large teams Small/Medium teams Any size
Release Rhythm Version-based Continuous Delivery Continuous Delivery
Hotfix hotfix branch feature branch feature branch
Multi-version Maintenance ✅ Supported ❌ Not Supported ⚠️ Limited Support

The actual practice in big tech companies is often a hybrid model.

Google uses Trunk-Based internally, Alibaba uses a model similar to Git Flow but simplified, and Tencent recommends customizing based on their own situation.

Some might say: "Our team only has five people, isn't Git Flow too heavy?"

You can absolutely use a simplified version.

Keep only two long-term branches, master and develop, pull feature branches from develop, and pull hotfix branches from master.

Remove the release branch and use tags instead.

This "lightweight Git Flow" runs very smoothly in many small and medium-sized teams.

3. Branch Naming Conventions

Big tech companies have strict requirements for branch naming.

A clear branch name should allow someone to know at a glance what this branch is for.

3.1 Core Naming Rules

The branch naming format recommended by Tencent Cloud:

<type>/<content>

Common branch prefixes:

Prefix Purpose Example
feature/ New feature development feature/user-login
bugfix/ Bug fix bugfix/login-timeout
hotfix/ Emergency online fix hotfix/payment-crash
release/ Version release preparation release/v2.1.0
chore/ Build/tool changes chore/update-dependencies

3.2 Advanced Conventions (Standard in Big Tech)

Big tech companies typically add more constraints on top of the basic naming:

① Associated Ticket Number

Branch names must include the JIRA/ticketing system number:

feature/PROJ-123-user-login
hotfix/PROJ-456-payment-timeout

This way, you can directly trace back to the requirement or bug ticket from the branch name without digging through records.

② Semantic Description

The description part should be concise and clear, letting others know roughly what this branch changes:

# ❌ Incorrect
feature/aaa
feature/test
feature/111

# ✅ Correct
feature/user-authentication
feature/order-payment-refund
hotfix/memory-leak-in-cache

③ Version Number Specification

release and hotfix branches should include version numbers:

release/v2.1.0
hotfix/v2.0.1-payment-fix

4. Commit Message Specification

The commit message is the most easily overlooked, yet most important part of Git specifications in big tech companies.

4.1 Why Is the Commit Message So Important?

There are three core reasons why big tech companies value commit messages so highly:

Reason One: Foundation of Code Review. A good commit message allows reviewers to quickly understand the purpose and scope of each change, significantly improving review efficiency.

Reason Two: Automated Changelog Generation. Standardized commit messages can be directly parsed by tools to automatically generate version release logs.

Reason Three: Clues for Problem Tracing. When a bug appears online, git blame shows a clear commit description, not just a single word like "fix".

4.2 Conventional Commits: The Standard Answer in Big Tech

Big tech companies generally adopt the Conventional Commits specification.

The format is as follows:

<type>(<scope>): <subject>

type (Required): Describes the type of change in this commit:

type Meaning Example
feat New feature feat(user): add user login feature
fix Bug fix fix(api): fix interface timeout issue
docs Documentation update docs(readme): update deployment instructions
style Code formatting (no functional impact) style: unify indentation to 4 spaces
refactor Code refactoring refactor(order): optimize order query logic
perf Performance optimization perf(cache): optimize cache hit rate
test Test-related test(auth): add login unit tests
chore Build/tool changes chore: upgrade Spring Boot version

scope (Optional): Describes the scope of the change's impact. For example, user in feat(user) indicates the change involves the user module.

subject (Required): A short description:

Complete Examples:

git commit -m "feat(user): add user login feature"
git commit -m "fix(api): fix interface timeout issue"
git commit -m "docs(readme): update project description document"
git commit -m "refactor(order): split order Service class"

4.3 Long Commit Messages

If a detailed explanation is needed, you can write multiple lines:

fix(payment): fix payment callback timeout issue

Cause: The third-party payment interface response time is unstable, exceeding the 30-second timeout threshold

Solution:
- Adjusted the timeout from 30 seconds to 60 seconds
- Added a retry mechanism (up to 3 times)
- Added a fallback plan to log the exception and return a processing status after timeout

Scope of Impact: PaymentService.handleCallback method
Test Status: Passed unit tests and integration tests

4.4 Several Core Principles

Principle One: Each commit solves one or one type of problem. Do not cram multiple unrelated changes into a single commit.

Principle Two: The amount of code committed should not be too large. It is recommended that a single commit does not exceed 300 lines. Big tech companies generally require each PR not to exceed 500-800 lines.

Principle Three: Ensure the code has passed self-testing before committing. Do not commit code that "should probably work."

5. Code Review

Branching strategy and commit specifications solve the "how to write" problem; Code Review solves the "how to ensure quality" problem.

5.1 Why Do Code Review?

The importance big tech companies place on Code Review far exceeds most people's imagination.

The core value of Code Review lies in three points:

Value One: Early Bug Detection. Code Review can find problems that testing can find, and it can also find problems that testing cannot (like design flaws, performance risks).

Value Two: Knowledge Transfer. Newcomers can quickly understand project conventions and best practices by reviewing the code of senior employees.

Value Three: Unified Code Style. Inconsistent styles are the biggest fear in multi-person collaboration; Code Review is the last line of defense to enforce style conventions.

5.2 Branch Protection Rules

Big tech companies enforce Code Review through branch protection rules:

image.png

5.3 PR Template

Big tech companies typically provide a standardized PR template to ensure sufficient information for each code review:

## Change Description
<!-- Briefly describe the content of this change -->

## Related Issue
<!-- Associated JIRA/Ticket Number -->
- #12345

## Change Content
- [ ] Modified login logic
- [ ] Added unit tests
- [ ] Updated related documentation

## Test Status
- [ ] Passed local self-testing
- [ ] Unit test coverage ≥ 80%
- [ ] Integration tests passed

## Checklist
- [ ] Code conforms to project style guide
- [ ] No unnecessary dependencies introduced
- [ ] No breaking changes to existing functionality
- [ ] No sensitive information (passwords/keys) committed

5.4 Review Checklist

What PR reviewers should check:

6. Automation Toolchain

Some might say: "The specifications are written, but what if the team doesn't follow them?"

The solution in big tech companies is: Use tools to enforce implementation, rather than relying on self-discipline.

6.1 Commit Message Validation (Commitlint)

Use Commitlint + Husky to automatically validate the commit message format during git commit.

Configuration Example:

// commitlint.config.js
module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [2, 'always', [
      'feat', 'fix', 'docs', 'style', 'refactor', 
      'perf', 'test', 'chore', 'revert'
    ]],
    'subject-max-length': [2, 'always', 50],
    'body-max-line-length': [2, 'always', 72]
  }
};

Combine with Husky to execute validation in the commit-msg hook:

// .husky/commit-msg
#!/bin/sh
npx --no -- commitlint --edit $1

Commits that do not conform to the specification will be directly rejected and cannot be submitted.

6.2 Branch Naming Validation

Validate whether branch names conform to specifications through Git hooks or CI tools.

Alibaba Cloud provides repository specification settings that can enforce branch naming rules and merge directions.

Validation Logic Example:

# Check if branch name conforms to specification
branch_name=$(git symbolic-ref --short HEAD)
if [[ ! $branch_name =~ ^(feature|bugfix|hotfix|release|chore)/ ]]; then
    echo "❌ Branch name does not conform to specification, please use feature/, bugfix/, hotfix/, release/, or chore/ prefix"
    exit 1
fi

6.3 Pre-commit Code Checks

Automatically execute formatting and static checks before code submission:

Code that does not conform to specifications or has syntax errors cannot pass the pre-commit check and thus cannot be submitted.

6.4 CI/CD Quality Gates

The CI/CD pipelines of big tech companies typically set up multiple layers of quality gates:

If any gate fails, the code cannot be merged into the main branch.

7. Tag Management: The "Milestones" of Version Releases

Big tech companies have strict Tag management specifications for version releases.

7.1 Semantic Versioning

Version numbers follow the Semantic Versioning specification:

MAJOR.MINOR.PATCH

7.2 Tag Creation and Push

# Create an annotated tag
git tag -a v2.1.0 -m "Release version 2.1.0"

# Push tag to remote
git push origin v2.1.0

# Push all tags
git push origin --tags

8. Core Process Panorama

Stringing all the above specifications together, a complete Git workflow should look like this:

image.png

9. Summary of Pros and Cons

Advantages of Git Specifications

1. Team collaboration efficiency is significantly improved With clear branch naming and standardized commit messages, team members can understand each other's changes without extra communication.

2. Code quality is guaranteed The dual guarantee of Code Review + CI gates makes it very difficult for problematic code to be merged into the main branch.

3. Problem tracing is fast and accurate Standardized commit messages combined with git blame allow for quick location of specific changes and authors when online bugs occur.

4. High degree of automation Standardized commit messages can be directly used to automatically generate changelogs and determine version numbers, significantly reducing manual operations.

5. Newcomers get up to speed quickly Unified specifications allow newcomers to quickly understand the project's development process and code evolution history.

Disadvantages

1. Specifications require tool support Without tools to enforce implementation, specifications are just a piece of waste paper.

Requires coordination with tools like Commitlint, Husky, and CI gates.

2. Initial adaptation cost When a team switches from "free mode" to "specification mode," there will be some discomfort and resistance in the first few weeks.

3. Requires continuous maintenance Specifications are not written once and done; they need continuous adjustment based on team size and business changes.

4. Do not over-engineer The purpose of specifications is to "save trouble," not to "manage people." Overly complex specifications can actually reduce development efficiency.

For more project-based practices, visit the Java Commando Network: susan.net.cn/project

10. Final Words

Returning to the initial question: Why do big tech companies value Git specifications so much?

Because when a team expands from a few people to hundreds, the cost of chaos grows exponentially.

A non-standard branch name could lead to a deployment accident; an unclear commit message could add two extra hours to troubleshooting an online issue; a merge without Code Review could introduce a bug into the production environment.

Specifications are not meant to constrain you, but to protect you.

The value of Git specifications lies not in how "nice" they look, but in enabling hundreds of people to collaborate efficiently in the same codebase without interfering with each other.

If you are just starting to value Git specifications now, it is recommended to start with three things:

Step 1: Unify the commit message format. This is the optimization with the highest return on investment—use the Conventional Commits specification, combined with Commitlint for mandatory validation.

Step 2: Establish a branching model. Even a simplified version—master for production, develop for development, feature/* for feature development.

Step 3: Enable Code Review. Start with "at least one person looks at every merge" and gradually build the habit.

Once these three things are done, your team's code quality and collaboration efficiency will see a visible improvement.

Good habits are the best lubricant for team collaboration.