跳到主要内容

Git 工作流

当文字类工作需要协作时，需要采用工作流，来处理内容的分工和组合。

常见的工作流有：

  • 中心化的工作流
  • Fork 工作流
  • Gitflow 工作流

中心化的工作流​

和 SVN 一样，大家仅在一个仓库一个分支上操作，参与者克隆仓库协作。

和远程仓库之间操作是：

# 本地每次变更提交后，需要整合远程仓库内容
git pull --rebase origin main

# 如果内容有关联会出现冲突，解决冲突，本地验证

# 然后再推送本地变更
git push origin main

Fork 工作流​

开源社区常用，会有一个官方仓库、多个贡献者仓库。主要步骤是：

  1. 开发者先从官方仓库分叉 (Fork) 出来一个仓库副本到自己空间下
  2. 克隆自己空间下的副本仓库到本地，进行编辑
  3. 推送变更内容到自己空间下的副本仓库
  4. 向官方仓库发起 Pull Request
  5. 官方仓库维护者评审和验证变更
  6. 通过评审和验证，则合并进官方仓库

Fork 工作流中，一般设定 upstream 为官方仓库：

git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git

# 当官方项目已经向前推进，则需获取官方新的提交内容
git pull upstream main  /  git merge upstream/main

查看副本仓库：

$ git remote -v
# origin 是 clone 时默认创建的
> origin    https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch)
> origin    https://github.com/YOUR_USERNAME/YOUR_FORK.git (push)
# upstream 是后来设定获取官方更新
> upstream  https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (fetch)
> upstream  https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (push)

Fork 工作流中，官方仓库管理员不用给每个参与的开发者分配权限。

Gitflow 工作流​

Gitflow 工作流，协作者在一个仓库中基于分支隔离不同阶段、不同范围的数据内容。

主要操作方式是：

  • 划分出用于“主分支、发布版本、临时协作”三种不同用途的分支
  • 发布版本用分支，有正常版本发布、维护版本发布，不同团队操作方式不一
    • 强版本的是 feature|release/<version_number> + tag → main，封版后会将内容合并进主分支，并删除发布版本分支
    • 重交付的是 develop → qa → staging → production + tag
  • 临时协作用分支，比较统一
    • feature，功能分支，用于处理当前阶段任务，来自版本分支
    • bugfix，Bug 分支，修复不紧急 Bug，来自正式环境、或测试环境
    • hotfix，Bug 分支，修复紧急 Bug，来自正式环境
(配图仅示例)

Gitflow 工作流，通过定义一个严格的分支和合并模型，用来管理发布周期，能明确的沿着路线图演进，又能应对未知异常和危险情况，提升项目稳健性。

不同类型、不同规模、不同交付方式项目，采用合适的协作工作流，帮助我们解决问题，要避免被其束缚掣肘。

最后由 XiangHongAi 于 更新