Long-lived branches and feature branches

In version control systems, branch management is one of the core functionalities. Long-lived branches and feature branches are two common strategies, each suited to different scenarios. Long-lived branches are typically used for stable releases or continuous integration, while feature branches focus on short-term feature development. Combining both can effectively balance stability and flexibility.

Role and Examples of Long-Lived Branches

Long-lived branches (e.g., main, develop) are usually tied to the software lifecycle. For example, a frontend project might design its branch structure as follows:

# View the list of long-lived branches
git branch -a
* main
  develop
  hotfix/1.2.1

In a typical workflow:

1. The main branch always contains production-ready code.
2. The develop branch is the integration branch, from which daily builds are triggered.
3. Each minor version (e.g., v1.3) is branched out from develop as a release branch.

The React project adopts a similar model, where its main branch is always kept in a releasable state, while experimental features are developed in separate branches.

Practical Applications of Feature Branches

Feature branches are temporary branches, usually prefixed with feature/. For example, when developing a shopping cart feature:

git checkout -b feature/shopping-cart

A typical workflow in a frontend project:

// Example commits during development
function addToCart(item) {
  // New feature code
  commit('feat: Implement basic shopping cart logic');
  
  // Fixing a discovered bug
  commit('fix: Correct item quantity calculation error');
}

Feature branches typically have a lifespan of no more than two weeks and should be merged immediately after completion. Vue 3's Composition API was developed in the feature branch feature/composition-api.

Comparative Analysis of Branch Strategies

The Angular team uses a hybrid strategy: the long-lived branch stable is used for releases, while each new feature (e.g., the Ivy renderer) is developed in an independent branch.

Best Practices for Conflict Resolution

When conflicts arise between long-lived and feature branches, rebasing is recommended over merging:

# Execute on the feature branch
git fetch origin
git rebase origin/develop

Common conflict scenarios in frontend projects:

/* Styles in the long-lived branch */
.container {
  width: 100%;
}

/* Modified rule in the feature branch */
.container {
  width: 100vw;
}

When resolving conflicts:

1. Preserve the semantics of both changes.
2. Add comments to explain compatibility logic.
3. Create new CSS class names if necessary.

Integration with Automation Tools

Modern CI/CD tools can optimize branch management. For example, a GitHub Actions configuration:

name: Feature Branch CI
on:
  pull_request:
    branches: [ develop ]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm ci
      - run: npm test

Build tools like Webpack can distinguish branches using environment variables:

// webpack.config.js
const isFeatureBranch = process.env.GIT_BRANCH.includes('feature/');

Suggested Branch Naming Conventions

Effective naming conventions should include:

• Type prefix (feature/, bugfix/)
• Associated issue number (PROJ-123)
• Brief description (using hyphens)

Bad example:

git checkout -b fix-bug  # Too vague

Good example:

git checkout -b bugfix/PROJ-456-header-overflow

The TypeScript official repository uses this convention, e.g., release-4.7 for version branches.

Techniques for Maintaining History

Use git log to view branch topology:

git log --graph --oneline --all

For frontend monorepo projects, combine with:

git log -- packages/components/

Particularly useful option combinations:

git log --pretty=format:"%h - %an, %ar : %s" -n 5

Considerations for Branch Deletion

Feature branches should be deleted promptly after merging:

# Local deletion
git branch -d feature/payment

# Remote deletion
git push origin --delete feature/payment

Exceptions where branches should be retained:

1. Code requiring legal review.
2. Long-running A/B tests.
3. Backups for important versions.

Adjustments in Enterprise-Level Projects

Large teams may need to extend the model:

main
├── develop
│   ├── feature/team-a/component
│   ├── feature/team-b/api
│   └── release/2.3
└── hotfix/2.2.1

Microsoft's VS Code project uses a similar structure, freezing the release branch for each iteration cycle.