Git 中的 Develop Branch — 是什么、目的和工作原理

Git 中的 Develop Branch 是什么

Develop Branch（开发分支）— 是 Git Flow 中的一个长期分支，作为所有开发人员代码集成的中心节点。开发完成并通过代码审查后，feature 分支合并到其中。

develop 中的代码始终处于准备创建发布的状态，尽管尚未发布到生产环境。这意味着 develop 中的所有功能都经过了审查、测试和集成检查，但仍在其发布周期中等待。

与 main 不同（每个代码版本都是一个发布），develop 包含持续的更改流。随着 feature 分支的合并，develop 中会出现 commit，这每天可能发生多次。

根据 Vincent Driessen，2010 的数据，develop 是成功分支模型的关键要素，因为它将正在进行的工作与准备发布的版本分开。

develop 和 main branch 的区别

理解 develop 和 main 之间的区别对于在 Git Flow 中正确工作至关重要。这些分支执行不同的功能，并且对稳定性有不同的要求。

将 develop 和 main 分开可以让团队持续集成新代码，而不会危及生产版本的稳定性。开发人员可以在 PR 批准后立即在 develop 中看到他们的代码，甚至在正式发布之前。

develop 在 Git Flow 中的作用

在 Git Flow 模型中，develop 位于 feature 分支（更改来源）和 release 分支（发布准备）之间。理解这种层次结构是有效分支的基础。

• Feature → Develop — 每个完成的功能通过带有代码审查的 Pull Request 合并到 develop。
• Develop → Release — 当积累足够的更改用于发布时，从 develop 创建 release 分支。
• Release → Main + Develop — 在最终准备之后，release 分支合并到 main（发布）并返回到 develop（错误修复）。
• Hotfix → Main + Develop — 关键修复从 main 创建并合并到两个分支。

这样的结构保证了 develop 始终包含最新版本的所有新功能代码，而 main 只包含经过验证的生产代码。这对于在 App Store 和 Google Play 中审查周期长的移动项目尤其重要。

develop 与其他 Git Flow 分支的关系

Develop 是 feature、release 和 hotfix 分支之间的中心环节。理解合并方向是防止冲突和丢失 commit 的基础。

develop 中的代码质量要求

代码质量 在 develop 中必须高，但不是绝对的。与 main 不同（每个错误都意味着紧急 hotfix），develop 允许在发布前修复的小缺陷。

合并到 develop 之前代码的最低要求：

• 编译 — 代码必须无错误地编译。develop 中的编译失败会阻塞整个团队的工作。
• 单元测试 — 所有现有测试必须通过。新代码的测试覆盖率必须至少达到 70%。
• Code style — 代码必须符合团队接受的格式和命名标准。
• 没有弃用的 API — 新代码中不允许使用已弃用的方法。

CI/CD 流水线中的自动检查应在每次推送到 develop 时运行。如果编译失败，负责的开发人员必须在一小时内修复问题或回退其 commit。

develop 的 CI/CD 检查

为 develop 配置 GitHub Actions 可确保每个 PR 在合并前通过自动检查。典型的流水线包括编译、测试和 linting。

# GitHub Actions — 合并后检查 develop
name: Develop CI

on:
  pull_request:
    branches: [develop]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Unit tests
        run: ./gradlew testDebug
      - name: Lint
        run: ./gradlew lint
      - name: Build
        run: ./gradlew assembleDebug

合并到 develop 的规则

合并到 develop 必须遵守严格的规则以保持集成分支的稳定性。违反这些规则会导致冲突、编译失败和团队时间损失。

• 仅通过 Pull Request — 禁止直接推送到 develop。所有更改都经过代码审查。
• 至少一个批准 — PR 必须获得至少一个未参与任务的开发人员的批准。
• Squash merge — 建议在合并到 develop 时将所有 feature 分支的 commit 合并为一个，以保持历史清晰。
• PR 的时效性 — 在合并之前，PR 必须相对于 develop 的最新 commit 进行更新（rebase 或 merge）。

PR 的时效性 规则尤为重要。如果 feature 分支是一周前创建的，而 develop 已经前进了 50 个 commit，直接合并可能导致冲突，最好在 PR 的上下文中解决，而不是在 develop 中。

保护 develop 免受错误合并

Branch protection rules（分支保护规则）— 是 GitHub、GitLab 或 Bitbucket 级别的设置，用于防止 develop 中的错误更改。它们保证即使是意外的推送也不会破坏集成分支。

推荐的 develop 保护规则：

• Require pull request — 禁止直接推送到 develop。所有更改仅通过 PR。
• Require approvals — 在合并 PR 之前至少 1-2 个批准。
• Require status checks — 如果 CI/CD 流水线未通过，则阻止合并。
• Require up-to-date — PR 分支必须在合并前相对于 develop 进行更新。
• Restrict push access — 限制只有高级开发人员才能推送到 develop。

配置 develop 保护需要 10 分钟，但可以防止因集成分支损坏而导致数周的停机。对于拥有多平台团队的移动项目来说，这一点尤为重要。

使用 develop 的命令示例

让我们看一个典型的开发人员工作日：早上他更新 develop，创建一个新的 feature 分支，完成任务后，将更改合并回 develop。

# 早上同步 develop
git checkout develop
git pull origin develop

# 从 develop 创建新的 feature 分支
git checkout -b feature/add-push-notifications

# 开发功能中...
git add . && git commit -m "Add FCM integration"

# 开发期间更新 develop
git fetch origin develop
git rebase origin/develop

# PR 批准后 — 更新本地 develop
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

develop 中的 git pull 命令同时执行两个操作：git fetch（从服务器获取新的 commit）和 git merge（将它们与本地分支合并）。对于 develop，这是标准的同步方式。

在合并损坏后恢复 develop

如果破坏了编译的代码进入 develop，需要迅速采取行动。develop 每停机一小时，整个开发团队的工作就会被阻塞。

如果破坏了编译的代码进入 develop，请使用 git revert 创建一个新的 commit 来撤销有问题的更改。不要在 develop 中使用 git reset — 这会重写其他参与者已有的历史记录。

# 查找有问题的 commit
git log --oneline develop

# 通过 revert 撤销 commit（安全）
git revert a1b2c3d

# 将修复推送到远程 develop
git push origin develop

# 查看特定 commit 中的更改
git show a1b2c3d --stat