Git 工作流：概念、常用模型与 IDEA 实操

🎯 学习目标

掌握 Git 工作流的核心概念、四种主流工作流的运作方式，并了解如何在 IntelliJ IDEA 中实践。

一、概述：Git 工作流的价值与分类

1. 概念与目的

Git 工作流（Git Workflow） 通俗地讲，指的是团队在代码管理和协作中遵循的一套流程和规范。它定义了开发者如何创建分支、何时合并、如何提交以及代码如何从开发环境最终部署到生产环境。

• 目的： 更高效、更安全地实现团队协同工作，保证主干代码的稳定性和可维护性。

2. 主要工作流分类

不同的项目规模和团队习惯，会采用不同的工作流：

1. 集中式工作流 (Centralized Workflow)

2. 功能分支工作流 (Feature Branch Workflow)

3. GitFlow 工作流 (GitFlow Workflow)

4. Forking 工作流 (Forking Workflow)

5. 自定义工作流 (Custom Workflow)

二、四大常用工作流详解

1. 集中式工作流 (Centralized Workflow)

概念与原理

这是一种最简单的模型，类似于传统的 SVN/CVCS（集中式版本控制系统）。只有一个中心仓库（Hub），所有人都直接向这个中心仓库的 master 分支提交代码。

适用场景

小型项目、个人项目，或团队成员较少且相互信任度高的小团队。

核心操作

• 所有人克隆 (Clone) 主仓库。

• 所有人直接在 master 分支上进行修改。

• 推送 (Push) 前必须先拉取 (Pull) 并合并（解决冲突），确保不会覆盖他人的修改。

💡 IDEA 实践： 核心是 Pull $\rightarrow$ Commit $\rightarrow$ Push 的顺序操作。

2. 功能分支工作流 (Feature Branch Workflow)

概念与原理

这是 Git 最为推荐和常用的工作流。核心思想是：所有的功能开发都必须在一个专门的、隔离的 feature 分支上进行，而不是在主分支 (master/main) 上。

优势

• 隔离性： 保障了主分支 (master/main) 永远是稳定、可部署的代码。

• 协作性： 极大地促进了 Pull Request (PR) 机制的使用，让代码在合并前有充足的讨论和审查机会。

核心操作流程

1. 创建功能分支： 基于 master 或 dev 分支创建一个新的 feature-X 分支。

2. 开发与提交： 在 feature-X 上完成开发，并提交到本地仓库。

3. 推送与 PR： 将 feature-X 推送到远程仓库，并向目标分支（如 master 或 dev）发起 Pull Request。

4. 审查与合并： 维护者审查代码，通过后合并到目标分支。

💡 Git 命令创建远程分支：

基于 master 创建远程分支 testing：

$ git push origin master:testing

删除远程分支 test02：

$ git push origin --delete test02
# 或
$ git push origin :test02

3. GitFlow 工作流 (GitFlow Workflow)

概念与原理

GitFlow 是在功能分支工作流的基础上，定义了一个更严格、更复杂的 分支模型。它为不同目的的分支分配了明确的角色，适用于大型、长期维护的项目。

分支角色定义

4. Forking 工作流 (Forking Workflow)

概念与原理

这是一种分布式的工作流，每个开发者都有自己的服务端仓库（称为 Fork）。它适用于开源项目或大型、自发性的团队，特点是去中心化。

优势

项目维护者无需给所有贡献者写入权限，贡献者通过自己的 Fork 仓库提交，项目维护者通过 Pull Request 安全地拉取和集成代码。

核心操作流程

1. Forking： 贡献者在代码托管平台（如 GitHub/GitLab）上 Fork (复制) 项目维护者的官方仓库。

2. 克隆与修改： 贡献者克隆自己的 Fork 仓库到本地进行修改。

3. 推送： 贡献者推送到自己的远程 Fork 仓库。

4. Pull Request： 贡献者向官方仓库发起 Pull Request。

5. 集成： 维护者审查并合并 PR 到官方仓库的主分支。

三、Pull Requests 机制

Pull Request (PR) 或 Merge Request (MR) 是一种通知机制和代码审查流程。

• 本质： 开发者修改了他人的（或自己的分支）代码后，通知项目作者或管理员，请求他们将这些修改拉取 (Pull) 并合并到主干分支中。

• 价值： 提供了代码讨论、自动化测试、质量审核的机会。

• 适用： 可与功能分支、GitFlow、Forking 等工作流结合使用。不能用于集中式工作流（因为它要求仓库或分支不同）。

四、自定义工作流 (基于 GitFlow 简化)

您提供的自定义工作流是一个高效、实用的企业内部开发模型，基于 GitFlow 进行简化：

核心操作步骤（IDEA 视角）

1. 成员初始化与分支切换

目标： 成员克隆仓库后，将远程 dev-xxx 分支拉取到本地。

1. 克隆仓库：

   • File $\rightarrow$ New $\rightarrow$ Project from Version Control... (克隆远程仓库)。

2. 切换到个人分支：

   • 点击 IDEA 右下角的分支名称。

   • 选择 origin/dev-xxx $\rightarrow$ Checkout as new local branch (本地创建同名分支并切换)。

2. 日常开发与推送

1. 开发 / 修改文件 $\rightarrow$ Commit 到本地仓库。

2. 推送功能分支： Git 菜单 $\rightarrow$ Push...

   • 特别注意： 先拉 (Pull) $\rightarrow$ 后推 (Push)，以避免在个人功能分支上产生冲突。

3. 成员合并到 dev (Pull Request)

• 流程： 成员在功能完成后，通过代码托管平台（如 GitLab/Gitee）向 dev 分支发起 Pull Request。

• 管理员操作： 审查通过后，管理员在平台上直接合并 dev-xxx 到 dev。

4. 拉取 dev 分支更新（同步协作）

目的： 将其他成员合并到 dev 上的代码同步到自己的 dev-xxx 分支，保持代码最新。

1. 切换到 dev-xxx 分支。

2. 拉取 dev 代码： Git 菜单 $\rightarrow$ Pull... $\rightarrow$ 配置拉取 origin/dev 的代码并合并到当前分支 (dev-xxx)。

   • 如果 dev-xxx 和 dev 有冲突，在本地解决冲突，然后 Commit $\rightarrow$ Push。

5. dev 合并到 master

• 当 dev 分支的代码经过充分测试、达到发布标准时：

  • 流程： 向 master 分支发起 Pull Request。

  • 管理员操作： 确保 dev 稳定无误后，合并到 master。

6. 打标签（Tagging）

• 一旦 dev 合并到 master 并发布新版本：

  1. 切换到 master 分支。

  2. Git 菜单 $\rightarrow$ Tags... $\rightarrow$ 点击 + (New Tag)。

  3. 输入版本号（如 v1.0.0），点击 Create。

  4. 推送标签： 在 Tags 窗口中，右键标签 $\rightarrow$ Push Tag...，将标签同步到远程仓库。