Branch management strategy

Team collaboration standards and branch management strategies are indispensable in front-end development. A well-defined collaboration process can enhance development efficiency, reduce conflicts, and ensure code quality. A reasonable branch management strategy helps teams better handle requirements changes, version iterations, and emergency fixes.

Team Collaboration Standards

Unified Code Style

A unified code style is the foundation of team collaboration. Tools like ESLint, Prettier, or Stylelint can automate code formatting, minimizing unnecessary style disputes. For example, here’s an example of an ESLint configuration file:

// .eslintrc.js
module.exports = {
  extends: ['eslint:recommended', 'plugin:prettier/recommended'],
  rules: {
    'no-console': 'warn',
    'no-unused-vars': 'error',
    'prettier/prettier': [
      'error',
      {
        singleQuote: true,
        trailingComma: 'es5',
        tabWidth: 2,
      },
    ],
  },
};

Commit Message Standards

Clear commit messages help trace code change history. It is recommended to use the Conventional Commits standard, for example:

feat: Add user login functionality
fix: Resolve button click issue
docs: Update README documentation

Code Review Process

Code Review is a critical step in ensuring code quality. Teams should establish clear review criteria, such as:

1. Each submission must be reviewed by at least one other member.
2. Focus on code logic, performance optimization, and potential risks during reviews.
3. Use tools like GitHub Pull Requests or GitLab Merge Requests for collaboration.

Branch Management Strategies

Git Flow

Git Flow is a classic branch management model suitable for long-term projects. Key branches include:

• master: Production environment code.
• develop: Main development branch.
• feature/*: Feature development branches.
• release/*: Pre-release branches.
• hotfix/*: Emergency fix branches.

For example, the workflow for developing a new feature:

git checkout develop
git pull origin develop
git checkout -b feature/user-auth
# After development, submit
git push origin feature/user-auth

GitHub Flow

GitHub Flow is more lightweight and suitable for rapid iteration projects. Core rules:

1. The main branch is always deployable.
2. New features or fixes are branched from main.
3. Merge code via Pull Requests.

Example:

git checkout main
git pull origin main
git checkout -b fix/button-style
# After making changes, submit
git push origin fix/button-style

Trunk-Based Development

Trunk-Based Development (TBD) emphasizes frequent commits to the main branch (e.g., main), making it suitable for continuous delivery teams. Developers create short-lived branches locally and merge quickly:

git checkout main
git pull origin main
git checkout -b feat/add-search
# After development, merge directly
git checkout main
git merge feat/add-search

Branch Naming Conventions

Clear branch naming improves collaboration efficiency. Common naming conventions:

• feature/login-page: Feature development.
• fix/header-bug: Bug fixes.
• refactor/api-client: Code refactoring.
• docs/readme-update: Documentation updates.

Avoid vague names like update or test.

Conflict Resolution Strategies

Conflicts are inevitable during branch merges. Common solutions include:

1. Use git rebase to maintain a linear commit history:

   git checkout feature/login
   git rebase develop
   # After resolving conflicts, continue
   git rebase --continue
   

2. Prefer git merge --no-ff to preserve branch history:

   git checkout develop
   git merge --no-ff feature/login
   

Automation Tool Integration

Leverage CI/CD tools to automate branch management workflows. For example, a GitHub Actions configuration:

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - run: npm install
      - run: npm test
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - run: npm install
      - run: npm run lint

Environment and Branch Mapping

Define the relationship between branches and deployment environments:

• main → Production environment
• develop → Testing environment
• feature/* → Local development environment

Use tools like dotenv to manage environment variables:

// config.js
require('dotenv').config({ path: `.env.${process.env.NODE_ENV}` });

Long-Lived vs. Short-Lived Branches

• Long-lived branches: Such as main, develop, require regular synchronization with upstream changes.
• Short-lived branches: Such as feature branches, should be deleted immediately after merging.

Command to clean up remote branches:

git fetch --prune

Code Rollback Strategies

Quickly revert incorrect merges:

1. Use git revert to create a reverse commit:

   git revert <commit-hash>
   

2. In emergencies, reset the branch:

   git reset --hard <commit-hash>
   git push -f origin main