版本控制基础：Git核心概念与CI/CD集成

说实话，版本控制这件事，我见过太多团队栽跟头了。有的项目代码乱成一锅粥，有的合并冲突能吵一整天。其实核心就那几个概念，搞明白了，后面的事就顺了。

Git核心概念：仓库、提交、分支、合并

先聊聊仓库。仓库说白了就是你的项目文件夹加上Git的"小本本"。这个小本本记录着每一次改动。我个人习惯，新项目第一件事就是 git init，把项目纳入版本控制。

提交是Git的灵魂。每次提交就像给代码拍了一张快照。我经常跟团队说：提交要小、要频繁、要有意义。别攒了一周的改动一次性提交，那谁也看不懂。

# 好的提交习惯
git add src/utils/helper.js     # 只提交相关文件
git commit -m "fix: 修复日期格式化时区问题"  # 写清楚改动原因

分支这东西，我刚开始用的时候也犯过迷糊。其实很简单——分支就是一条独立的时间线。主分支（main/master）是稳定的，开发分支（develop）是日常工作的，功能分支（feature/*）是干活的。

合并嘛，就是把两条时间线接起来。这里有个坑——合并冲突。我曾经因为一个配置文件冲突，折腾了半小时。后来学乖了，合并前先 git pull --rebase，把本地提交放到最新代码上面，冲突少很多。

Git工作流：GitFlow vs Trunk-Based

工作流这东西，没有银弹。我两种都用过，说说我的感受。

特性	GitFlow	Trunk-Based
分支数量	多（main, develop, feature, release, hotfix）	少（主要就 main 和短生命周期分支）
适合场景	大型项目、版本发布周期长	持续交付、微服务、小团队
合并频率	低（按版本合并）	高（每天合并多次）
学习成本	较高	低

GitFlow 适合那种有固定发布周期的项目。比如一个月发一个版本，有专门的测试阶段。我在做企业级项目时用过，分支管理很清晰，但确实有点重。

Trunk-Based 是我现在更偏好的方式。说白了就是大家都在主干上开发，分支只存活一两天。你想想看，这样合并冲突少，CI跑得快，出了问题也容易回滚。

代码托管平台的CI/CD集成

GitHub和GitLab都内置了CI/CD能力。说白了就是：你推代码，它自动跑测试、构建、部署。

GitHub Actions 的配置很直观。我一般这样写：

# .github/workflows/ci.yml
name: CI Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: 安装依赖
        run: npm ci
      - name: 运行测试
        run: npm test
      - name: 代码质量检查
        run: npm run lint

GitLab CI 的配置类似，但用 .gitlab-ci.yml：

# .gitlab-ci.yml
stages:
  - test
  - build
  - deploy

unit-test:
  stage: test
  script:
    - npm ci
    - npm test
  only:
    - main
    - merge_requests

知识体系总览

下面这张图是我自己整理的版本控制知识体系。你看一眼，心里就有谱了。

这张图把今天的内容串起来了。从Git核心概念出发，到工作流选择，再到CI/CD集成，每一步都有讲究。我个人觉得，版本控制这件事，70%靠规范，30%靠工具。规范定好了，工具只是辅助。