Git 工作流

wingmeng
395 阅读5分钟

本文分享一种基于 Git 的开发工作流，力求简单轻量，适用于小型团队。其工作模式参考了 gitlab-flow(with production) 工作流。

分支说明

  1. master 【永久分支】【受保护】，有且只有一个，用于接收开发者代码的并入，始终保持最新完成的代码。
  2. production 【永久分支】【受保护】，有且只有一个，会按阶段对 master 分支进行“合并”（merge），用于生产环境（线上）的版本。
  3. feature-<Issue ID>_[Tag] 【临时分支】，功能开发分支，可以有多个，各个 feature 分支之间的代码是隔离的，可独立地开发、构建、测试。
  4. bugfix-<Issue ID> 【临时分支】，bug 修复分支，可以有多个。

分支规则

  • 永久分支不会被删除，包括开发分支 master 和生产分支 production。
  • 临时分支分为功能分支 Feature 和修复分支 Bugfix，在开发完成会被删除。
  • 功能分支必须对应需求，修复分支必须对应 Bug。不要创建无关分支。
  • 临时分支的建立需从 master 分支创建，并在开发过程中实时合并 master 的变更。
  • Feature 和 Bugfix 分支由开发人员在开发环境下完成测试，master 分支在测试环境中部署测试，production 分支在仿真环境下部署测试（如有条件的话）。

提交规则

  • 操作说明

    • Git 每次提交代码，都要写 Commit message（提交说明），否则不允许提交；
    • Commit message 不限中英文，内容应清晰明了，说明本次提交的目的；
    • 及时通过 git commit 提交内容，不要在一个 commit 里提交太多的变更；
    • 及时地从 master pull 代码，早做 merge，否则可能面临大量的冲突，merge 会非常痛苦和易出错；
    • 如从 master pull 下来的代码与本地产生了冲突，务必解决冲突后再提交，必要时还要找相关开发者当面确认；
    • 确保每次 push 之前都先 pull 一次；
    • 通过 Pull request 提交到 master 的代码，需确保不影响项目其他成员。

  • git commit 模板

    <type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

    • type【必填】用于说明 commit 的类别，只允许使用下面几种标识：

      分类 说明
      feat 新功能
      fix 修复 bug
      docs 文档
      style 仅修改了缩进、格式、符号等，未改变代码逻辑
      refactor 重构（即不是新增功能，也不是修改 bug 的代码变动）
      test 增加测试用例
      build 依赖相关的内容
      ci CI 配置相关
      chore 改变构建流程，或者增加依赖库、工具等
      revert 回滚到上一个版本

    • scope【可选】用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

    • subject【必填】本次 commit 的主题（简短描述），规则如下：

      • 以动词开头，使用第一人称现在时；
      • 不超过 20 个字符；
      • 结尾不加句号。

    • Body【可选】对本次 commit 的详细描述，可以分成多行。

    • Footer【可选】备注信息，可以在 Footer 部分关闭 issue。

开发流程

  1. PM 将需求按开发角色划分，按如下要求在项目仓库创建对应的 Issue：

    1. 用一句话描述需求作为标题。
    2. 在描述正文中阐明功能点或说明当前需求是解决什么问题的。
    3. 拆分出具体的开发任务，通过复选框的勾选与否来标明进度。
    4. 指派开发者（可选），设置开发期限（可选），选择里程碑（可选）。
    5. 为其打上 Labels（分类、进度、优先级），方便之后的筛选、排期等工作。

  2. 开发者认领属于自己的需求 Issue，创建与 Issue 对应的分支，同时将进度 Labels 的状态从“计划中”改为“开发中”。

  3. 开发者在本地创建同名新分支，并从远端同名分支拉取资源。

  4. 开发者在本地进度功能开发，通过 git commit 不断提交代码，并按阶段在对应 Issue 中标记相关功能点的完成进度。当前功能全部开发完成后，开发者将进度 Labels 的状态从“开发中”改为“测试中”，进入本地测试环节。

  5. 从 master 分支获取远端最新代码，进行本地 merge，如产生代码冲突，务必先解决冲突。

  6. 在本地 merge 无误后推送代码到远端对应的功能分支。

  7. 在项目仓库的网页上发起对 master 分支的 pull request 请求。

  8. 审核无误后，将代码 merge 进 master 主干分支，同时删除功能分支；修改当前 PR 对应的 Issue 进度 Labels 从“测试中”变为“已合入”，同时关闭该 Issue；开发者自行删除本地的功能分支。

发布流程

  1. 管理员从 master 分支拉取稳定代码到 production 分支。
  2. 进行版本测试，如测试出 bug，则创建对应的 bug Issue。
  3. 开发者认领属于自己的 Issue，创建相关的修复分支。
  4. 开发者在本地创建同名分支，并从远端同名分支拉取资源。
  5. 开发者在本地进度 bug 修复，通过 git commit 提交代码，完成后进行本地测试。
  6. 本地测试无误后，将代码推送到远端对应分支。
  7. 发起对 master 分支的 PR 请求。
  8. 审核无误后，将代码 merge 进 production 分支，同时删除修复分支；修改当前 Issue 进度 Labels 状态，同时关闭该 Issue；开发者自行删除本地的修复分支。
  9. 当 production 分支中的所有 bug 被修复后，为其打上版本号 tag 标签。版本号按照 x.y.z 的格式。
  10. 将修复的变动 cherry-pick 到 master 主干分支。

相关插件

avatar
文章
阅读
粉丝