In collaborative Git development, branch management acts as an invisible “traffic rule,” ensuring orderly code changes and avoiding chaos. Without a standardized branching strategy, team members might overwrite each other’s files, causing conflicts, functional messes, or deployment failures. This article simplifies why branching is necessary and how to standardize Git usage in teams.

Why Branch Management Matters?¶

Imagine two developers editing login.js simultaneously. Directly committing to the main branch would cause code conflicts—the system can’t decide which changes to keep. Worse, pushing code directly to the main branch could break the project entirely.

The core purpose of branching is to isolate development on independent “lines”, allowing parallel work before merging results. Think of it as a main road (main branch) splitting into multiple side roads (feature branches), where everyone works independently before connecting the roads back.

Git Branch Basics: From “Single Line” to “Multiple Paths”¶

What is a Branch?¶

A branch is essentially a separate line of code versions. By default, Git starts with one main branch (often master or main). Creating a new branch copies the current code state, letting you modify it without affecting the main branch.

Common Branch Types¶

• Main Branch (main/master): Always holds deployable, stable code—only merges are allowed, no direct commits.
• Feature Branch (feature/*): Develop new features (e.g., feature/user-center).
• Bugfix Branch (bugfix/*): Fix bugs (e.g., bugfix/login-error).
• Hotfix Branch (hotfix/*): Urgently fix production issues (e.g., server crashes) and merge to main first.

Beginner-Friendly Strategy: Simplified GitHub Flow¶

Complex strategies like Git Flow are too steep for beginners. We recommend GitHub Flow—simple and effective:
The main branch is always deployable; all work happens via “branch → develop → merge PR.”

1. Main Branch (main): Always “Clean and Deployable”¶

• Only merged code is pushed to main, and main must run without issues.
• Never commit directly to main (unless an emergency fix is unavoidable).

2. Feature Branch (feature/*): Isolated Development¶

• Create a branch from the latest main code:

  git checkout main       # Switch to main branch
  git pull origin main    # Fetch latest changes
  git checkout -b feature/user-center  # Create and switch to feature branch

• Develop and commit changes:

  git add .               # Stage all changes
  git commit -m "feat: Complete user center layout"  # Use clear commit messages

• Push to remote for collaboration:

  git push -u origin feature/user-center  # -u links to remote; future pushes use `git push`

3. Merge via PR/MR: Enforce Code Review¶

• After pushing to the remote, create a Pull Request (PR) or Merge Request (MR) on platforms like GitHub/GitLab.
• Team members review code (logic, style, bugs). After approval, merge to main.
• Delete the feature branch (both local and remote) to avoid clutter.

Team Collaboration Norms: Unspoken Agreements¶

1. Branch Naming Rules (Clarity First)¶

• Feature: feature/description (e.g., feature/wechat-login).
• Bugfix: bugfix/issue-description (e.g., bugfix/login-crash).
• Hotfix: hotfix/critical-issue (e.g., hotfix/payment-error).

2. Commit Message Guidelines (Conventional Commits)¶

Use standardized commit types:
- feat: New feature
- fix: Bug fix
- docs: Documentation
- refactor: Code restructuring

Example:

git commit -m "fix: Fix mobile button unresponsive issue"

3. Development Best Practices¶

• No direct pushes to main: Always use feature branches.
• Atomic commits: Focus on one task per commit (easier review/rollback).
• Sync with main regularly: Pull latest main changes to avoid large conflicts:

  git checkout feature/user-center
  git pull origin main  # Merge latest main into your branch

4. Code Review: Catch Issues Early¶

• Reviewers check logic, security, and code style.
• Use reviews to share knowledge and improve code quality.

Troubleshooting Common Issues¶

1. Resolving Branch Conflicts¶

If two people edit the same file:
1. Pull latest main: git pull origin main
2. Git marks conflicts with <<<<<<< HEAD (your changes), ======= (separator), and >>>>>>> <commit> (others’ changes).
3. Edit the file to remove markers and keep correct code.
4. Save and commit: git add . && git commit -m "merge: Resolve conflicts"

2. Fixing a Mistyped Commit Message¶

For un-pushed commits:

git commit --amend -m "fix: Correct avatar upload bug"

3. Cleaning Up Old Branches¶

After merging to main, delete feature branches:
- Remote: Delete via platform UI (e.g., GitHub’s “Delete branch”).
- Local:

  git checkout main
  git pull origin main
  git branch -d feature/old-feature  # Delete local branch

Conclusion¶

Git branching’s core is “standardization and collaboration”: isolate work with branches, reduce friction with norms, and improve quality through teamwork. For beginners, start with simplified GitHub Flow: branch → develop → PR → clean up.

A well-managed branch strategy turns chaos into efficiency, letting everyone focus on tasks instead of version conflicts. Start today, and watch your team’s workflow improve!