Git 从开发测试到上线的流程详解

Git 作为一个分布式版本控制系统，在现代软件开发中扮演着核心角色。它不仅能追踪代码变更、协调团队协作，还能支撑复杂的开发、测试到上线的全流程管理。本文将详细阐述基于 Git 的标准开发、测试到上线流程，旨在提供一个清晰、可操作的实践指南。

核心思想：利用 Git 的分支管理能力，清晰地划分开发阶段，确保代码质量，并实现高效、可追溯的部署。

一、Git 分支模型选择

在开始流程之前，选择一个合适的分支模型至关重要。常见的分支模型包括 Git Flow 和 GitHub Flow (或 GitLab Flow)。

1.1 Git Flow

Git Flow 是一种较为复杂的、结构化的分支模型，适用于发布周期较长、版本发布严格的项目。它定义了五种主要分支：

main (或 master) 分支：用于存放生产环境稳定代码。只有当代码准备好发布时，才合并到此分支。每次合并到 main 都应该打上版本标签。
develop 分支：用于存放最新开发完成的代码，是所有功能开发分支的集成点。
feature 分支：用于开发新功能。通常从 develop 分支创建，完成功能开发后合并回 develop。
release 分支：用于准备发布新版本。从 develop 分支创建，在此分支上进行 Bug 修复、版本号升级、发布前的最后测试。完成后合并到 main 和 develop。
hotfix 分支：用于紧急修复生产环境的 Bug。从 main 分支创建，修复完成后合并到 main 和 develop。

Git Flow 分支结构示意图：

    gitGraph
    commit
    commit id: "Initial Commit"
    branch develop
    checkout develop
    commit id: "Feature A start"
    branch feature-a
    checkout feature-a
    commit id: "Feature A work"
    checkout develop
    merge feature-a
    commit id: "Feature B start"
    branch feature-b
    checkout feature-b
    commit id: "Feature B work"
    checkout develop
    merge feature-b
    branch release-1.0
    checkout release-1.0
    commit id: "Bug fix on release"
    checkout main
    merge release-1.0 tag: "v1.0.0"
    checkout develop
    merge release-1.0
    branch hotfix-1.0.1
    checkout hotfix-1.0.1
    commit id: "Hotfix commit"
    checkout main
    merge hotfix-1.0.1 tag: "v1.0.1"
    checkout develop
    merge hotfix-1.0.1

1.2 GitHub Flow / GitLab Flow

GitHub Flow（或其演进的 GitLab Flow）是一种更简洁、更轻量级的模型，适用于持续集成/持续部署 (CI/CD) 环境，通常只有一个长期分支 (main 或 master)。

main (或 master) 分支：始终保持可部署状态。所有新功能和 Bug 修复都从 main 创建新分支，完成后通过 Pull Request (PR) 或 Merge Request (MR) 合并回 main。
feature / bugfix 分支：直接从 main 分支创建，开发完成后合并回 main。

GitHub Flow 分支结构示意图：

    gitGraph
    commit id: "Initial Commit"
    branch feature-a
    checkout feature-a
    commit id: "Feature A work"
    checkout main
    merge feature-a
    commit id: "Feature B start"
    branch feature-b
    checkout feature-b
    commit id: "Feature B work"
    checkout main
    merge feature-b
    commit id: "Hotfix commit"
    branch hotfix-c
    checkout hotfix-c
    commit id: "Hotfix work"
    checkout main
    merge hotfix-c

选择建议：

Git Flow：适合有明确版本发布周期、需要严格管理稳定版本的项目。
GitHub/GitLab Flow：适合快速迭代、持续部署、DevOps 实践的项目。

本文将以 Git Flow 为基础，结合实际项目，详细阐述从开发到上线的流程，同时也会提及 GitHub Flow 的简化思想。

二、开发流程详解

2.1 初始化仓库与克隆

项目启动时，首先需要初始化 Git 仓库。

初始化 (仅一次)：

git init
git add .
git commit -m "Initial commit"
git remote add origin <your_repository_url>
git push -u origin main

克隆仓库：

团队成员通过克隆现有仓库开始工作。

1
2
3

git clone <your_repository_url>
cd <repository_name>
git checkout develop # 如果使用Git Flow，切换到开发分支

2.2 功能开发 (Feature Branch Workflow)

从 develop 创建功能分支：
在开始新功能开发前，确保本地 develop 分支是最新的。
1
2
3
git checkout develop
git pull origin develop # 同步最新 develop
git checkout -b feature/your-feature-name # 创建并切换到新功能分支
命名规范： 通常使用 feature/ 或 feat/ 前缀，后跟功能描述。
进行功能开发与提交：
在功能分支上进行编码、调试和测试。定期提交代码，保持提交粒度小而清晰。
1
2
3
# 编辑文件...
git add .
git commit -m "feat: implement user registration form" # 提交信息遵循规范
提交信息规范 (Conventional Commits 推荐)：
- feat: 新功能
- fix: Bug 修复
- docs: 文档变更
- style: 代码格式 (不影响代码运行的变动)
- refactor: 重构 (不增加功能、不修复 Bug 的代码改动)
- perf: 性能优化
- test: 增加测试
- build: 构建系统或外部依赖的变更
- ci: CI 配置或脚本的变更
- chore: 其他不修改 src 或 test 文件的改动

推送功能分支到远程仓库：

1	git push -u origin feature/your-feature-name

2.3 代码审查与合并 (Pull Request / Merge Request)

功能开发完成后，需要将代码合并到 develop 分支。这一步通常通过 Pull Request (GitHub) 或 Merge Request (GitLab/Gitee) 进行。

发起 PR/MR：
在 Git 托管平台（如 GitHub、GitLab）上，从 feature/your-feature-name 分支向 develop 分支发起 PR/MR。
代码审查：
团队成员对代码进行审查，提出修改意见。这是确保代码质量、发现潜在 Bug 的关键环节。

解决冲突 (如有)：
如果 develop 分支在你的功能开发期间有新的提交，可能会导致合并冲突。你需要将 develop 分支的最新代码拉取到你的功能分支，解决冲突后再次提交。

git checkout feature/your-feature-name
git pull origin develop # 将 develop 最新代码合并到当前功能分支
# 解决冲突...
git add .
git commit -m "Merge develop and resolve conflicts"
git push origin feature/your-feature-name

或者使用 rebase 保持提交历史整洁：

git checkout feature/your-feature-name
git rebase develop # 将 develop 最新代码 rebase 到当前功能分支
# 解决冲突...
git add .
git rebase --continue
git push --force-with-lease origin feature/your-feature-name # rebase 后强制推送

注意： rebase 会改写历史，不建议在多人协作的公共分支上使用 rebase。功能分支如果是个人私有分支，且未被推送到远程仓库，可以使用 rebase。一旦推送到远程仓库，并且有其他人在该分支上工作，则避免使用 rebase，而是使用 merge。

批准与合并：
代码审查通过后，PR/MR 被批准，并将 feature 分支合并到 develop 分支。合并后，通常可以删除远程功能分支。

三、测试与预发布流程

当 develop 分支的代码积累了一定的功能并准备进行发布时，进入测试和预发布阶段。

3.1 创建 `release` 分支

从 develop 分支创建 release 分支，用于本次发布的所有准备工作。

1
2
3

git checkout develop
git pull origin develop
git checkout -b release/vX.Y.Z # 创建并切换到发布分支

命名规范： 通常使用 release/ 前缀，后跟版本号。

3.2 版本号管理与预发布环境部署

更新版本号：
在 release 分支上，更新项目的版本号（如 package.json, pom.xml 或其他配置文件）。
1
2
3
4
# 修改版本文件
git add .
git commit -m "chore: bump version to vX.Y.Z"
git push origin release/vX.Y.Z
部署到预发布环境 (Staging/UAT)：
配置 CI/CD 管道，当代码推送到 release 分支时，自动触发构建并将应用程序部署到预发布环境。
预发布环境应该尽可能模拟生产环境，包括硬件、网络、数据库等。

3.3 全面测试与 Bug 修复

在预发布环境上进行全面的测试，包括：

功能测试 (Functional Testing)：确保所有新功能和现有功能正常工作。
回归测试 (Regression Testing)：检查新改动是否引入了新的 Bug 或破坏了原有功能。
性能测试 (Performance Testing)：评估系统在压力下的表现。
安全测试 (Security Testing)：发现潜在的安全漏洞。
用户验收测试 (UAT - User Acceptance Testing)：邀请最终用户或产品经理进行测试，确认功能符合业务需求。

Bug 修复：
如果在 release 分支上发现 Bug，直接在 release 分支上进行修复和提交。

git checkout release/vX.Y.Z
# 修复 Bug...
git add .
git commit -m "fix: resolve critical bug in payment module"
git push origin release/vX.Y.Z

注意： release 分支一旦创建，就不再合并新的 feature 分支。所有 Bug 修复都应该在 release 分支上进行。

四、上线部署流程

当 release 分支经过全面测试，确定稳定后，就可以进行上线部署。

4.1 合并到 `main` 和 `develop`

合并到 main 分支：
将 release 分支合并到 main 分支，并打上版本标签。

git checkout main
git pull origin main # 确保 main 最新
git merge --no-ff release/vX.Y.Z # 使用 --no-ff 保持 release 分支的合并记录
git tag -a vX.Y.Z -m "Release vX.Y.Z" # 打上版本标签
git push origin main --tags # 推送 main 和标签

--no-ff (no fast-forward) 选项会强制创建一个新的合并提交，即使可以快进合并。这有助于保留 release 分支的完整历史，方便回溯。

合并到 develop 分支：
将 release 分支的 Bug 修复同步回 develop 分支，确保 develop 包含所有最新的 Bug 修复。
1
2
3
4
git checkout develop
git pull origin develop # 确保 develop 最新
git merge --no-ff release/vX.Y.Z
git push origin develop

删除 release 分支 (可选)：
发布完成后，可以删除本地和远程的 release 分支。

1 2	git branch -d release/vX.Y.Z # 删除本地分支 git push origin --delete release/vX.Y.Z # 删除远程分支

4.2 生产环境部署 (CI/CD)

触发部署：
当 main 分支收到新的合并提交或新的版本标签时，CI/CD 管道会自动触发生产环境的构建和部署。
部署策略：
根据项目需求选择合适的部署策略，例如：
- 蓝绿部署 (Blue/Green Deployment)：同时运行新旧两个环境，通过切换流量来完成部署。
- 金丝雀发布 (Canary Release)：逐步将流量切换到新版本，先让一小部分用户使用新版本，观察其表现。
- 滚动更新 (Rolling Update)：逐个替换旧版本实例为新版本实例。
发布验证：
部署完成后，进行生产环境的健康检查和冒烟测试，确保应用程序正常运行。
监控与告警：
持续监控生产环境的性能、错误日志和用户行为，及时发现并响应潜在问题。

五、紧急修复流程 (Hotfix Workflow)

当生产环境出现紧急 Bug 时，需要启动 hotfix 流程。

从 main 创建 hotfix 分支：
hotfix 分支直接从 main 分支创建，以确保修复是基于生产环境的代码。
1
2
3
git checkout main
git pull origin main
git checkout -b hotfix/vX.Y.Z.patch # 创建并切换到热修复分支
命名规范： 通常使用 hotfix/ 前缀，后跟版本号。

修复 Bug 并提交：
在 hotfix 分支上进行 Bug 修复。

# 修复 Bug...
git add .
git commit -m "fix: critical hotfix for production bug"
git push origin hotfix/vX.Y.Z.patch

部署到生产环境并合并：
hotfix 完成后，部署到生产环境进行验证。验证通过后，将 hotfix 分支合并回 main 和 develop，并打上版本标签。

# 合并到 main
git checkout main
git pull origin main
git merge --no-ff hotfix/vX.Y.Z.patch
git tag -a vX.Y.Z.patch -m "Hotfix Release vX.Y.Z.patch"
git push origin main --tags

# 合并到 develop
git checkout develop
git pull origin develop
git merge --no-ff hotfix/vX.Y.Z.patch
git push origin develop

# 删除 hotfix 分支 (可选)
git branch -d hotfix/vX.Y.Z.patch
git push origin --delete hotfix/vX.Y.Z.patch

六、CI/CD (持续集成/持续部署) 集成

CI/CD 是现代开发流程不可或缺的一部分，它能自动化构建、测试和部署，极大地提高了效率和可靠性。

6.1 持续集成 (CI - Continuous Integration)

目的：频繁地将代码集成到共享仓库，并通过自动化测试快速发现和修复集成问题。
实践：
- 每次 feature 分支向 develop 或 main 分支发起 PR/MR 时，自动触发 CI 管道。
- CI 管道执行以下操作：
  - 代码风格检查 (Linting)
  - 单元测试 (Unit Tests)
  - 集成测试 (Integration Tests)
  - 构建项目 (Build)
  - 生成测试报告和代码覆盖率报告
- 只有通过所有 CI 检查的代码才能被合并。

CI 流程示意图：

    graph TD
    A[开发者提交代码到功能分支] --> B{发起 Pull Request};
    B --> C[CI/CD 系统触发构建];
    C --> D[运行 Linting/格式化];
    D --> E[运行单元测试];
    E --> F[运行集成测试];
    F --> G[构建项目];
    G -- 失败 --> H[通知开发者和团队，中止合并];
    G -- 成功 --> I{代码审查通过?};
    I -- 否 --> H;
    I -- 是 --> J[合并到 develop/main 分支];

6.2 持续部署 (CD - Continuous Deployment) / 持续交付 (Continuous Delivery)

持续交付 (Continuous Delivery)：代码通过所有测试后，自动准备好随时可以部署到生产环境，但部署需要人工触发。
持续部署 (Continuous Deployment)：代码通过所有测试后，自动部署到生产环境，无需人工干预。
实践：
- 当代码合并到 develop 分支时，自动部署到开发/测试环境。
- 当 release 分支创建或更新时，自动部署到预发布环境。
- 当 main 分支收到新的版本标签或合并提交时，自动触发生产环境部署。

CD 流程示意图：

    graph TD
    A[代码合并到 develop/main] --> B[CI/CD 系统触发部署];
    B --> C[构建镜像/打包应用];
    C --> D[部署到测试/预发布环境];
    D --> E{手动/自动测试通过?};
    E -- 否 --> F[回滚或修复];
    E -- 是 --> G[部署到生产环境];
    G --> H[生产环境验证/监控];

6.3 示例 (Python + GitHub Actions)

以一个简单的 Python 项目为例，展示 CI 流程。

.github/workflows/ci.yml:

name: Python CI

on:
  push:
    branches:
      - main
      - develop
      - 'feature/**' # 匹配所有 feature 分支
  pull_request:
    branches:
      - main
      - develop

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout repository
      uses: actions/checkout@v3

    - name: Set up Python
      uses: actions/setup-python@v4
      with:
        python-version: '3.9' # 指定 Python 版本

    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install flake8 pytest

    - name: Lint with flake8
      run: |
        # stop the build if there are Python syntax errors or undefined names
        flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics
        # exit-zero treats all errors as warnings. The GitHub editor is 1-indexed for columns too
        flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics

    - name: Run tests with pytest
      run: |
        pytest

七、回滚与版本管理

7.1 版本标签 (Tags)

为 main 分支的每次发布打上版本标签 (例如 v1.0.0) 是非常重要的。标签可以清晰地标识发布版本，方便追溯和回滚。

1 2	git tag -a v1.0.0 -m "Release version 1.0.0" git push origin v1.0.0

7.2 回滚策略

当生产环境出现严重问题，无法通过快速修复解决时，可能需要回滚到上一个稳定版本。

基于标签回滚 (推荐)：
如果每次发布都打了标签，可以直接回滚到某个标签对应的提交。
1
2
3
4
5
6
# 查找上一个稳定版本的标签
git tag

# 回滚到指定标签的提交
git revert vX.Y.Z # 这会创建一个新的提交，撤销 vX.Y.Z 引入的变更
git push origin main
- git revert 是安全的回滚方式，它会创建一个新的提交来撤销之前的变更，保留了历史记录。
基于提交回滚：
如果知道要回滚到哪个提交，也可以直接 revert 该提交。
1
2
3
git log --pretty=oneline # 查看提交历史，找到要回滚的提交哈希
git revert <commit-hash>
git push origin main
- 警告：避免在已共享的公共分支上使用 git reset --hard 来回滚，因为它会改写历史，导致其他协作者的工作出现问题。reset 适用于撤销本地未推送的提交。