Git 工作流程

团队多人协作,必须要有一个适合团队的,规范的工作流程

协作必须有一个规范的工作流程,让大家有效地合作,使得项目井井有条地发展下去。"工作流程"在英语里,叫做"workflow"或者"flow",原意是水流,比喻项目像水流那样,顺畅、自然地向前流动,不会发生冲击、对撞、甚至漩涡。

市面上主要有3中工作流Git flow,Github flow,Gitlab flow。这里我们采用Git flow工作流

下面具体介绍该工作流

主要特点

首先,项目存在两个长期分支

  • 主分支master
  • 开发分支develop
    前者用于存放对外发布的版本,任何时候在这个分支拿到的,都是稳定的分布版;后者用于日常开发,存放最新的开发版。
    Git 工作流程_第1张图片(两个长期分支)

其次,项目存在三种短期分支

  • 功能分支(feature branch)
  • 补丁分支(hotfix branch)
  • 预发分支(release branch)(可用个人开发分支替代)

日常开发

  • 创建个人开发分支,基于远程 dev 创建

    git checkout -b feature-a origin/dev
  • 同步 dev 分支

    git rebase origin/dev
  • 完成开发,commit,push 远程。
  • 发起合入 dev 分支请求(使用 gitlab 新建合并请求)
  • 管理者接受合并请求,代码合并进入 dev 分支。

预发布版本测试、正式发版

  • 创建预发布分支(如:release-1.0.0),基于 dev 分支创建预发布分支
  • 测试预发布分支代码
  • 测试通过后,合入 master 分支
  • 正式发布版本,打版本 tag

bug 修复

预发布版本 bug 修复

  • 创建bug分支,基于预发布版本分支创建。(假设预发布版本分支为:release-1.0.0)

    git checkout -b 15-release-1.0.0-bug-a origin/release-1.0.0
    建议 bug 分支命名规范:与 issue 的名字保持一致,并且以issue的编号起首。如"15-release-1.0.0-bug-a "。
    开发完成后,在提交说明里面,可以写上"fixes #14"或者"closes #67"。Gitlab 规定,只要commit message里面有下面这些动词 + 编号,就会关闭对应的issue。
    如未创建 issue,去掉头部的编号。
  • 完成修复 bug ,本地提交(commit),push 远程。
  • 发起合入预发布版本分支(使用 gitlab 新建合并请求)。
  • 发起合入 dev 分支(使用 gitlab 新建合并请求)。

    注意:bug 修复完成后,同时需要合入 dev 分支
  • 管理者接受合并请求,代码合入目标分支。

master(线上) bug 修复

流程同 "预发布版本 bug 修复" 流程

区别在于

  • 创建分支是基于 master 分支创建
  • 分支名为 15-master-1.0.0-bug-a
  • bug 修复完成后,发起合入 master 分支和 dev 分支。

参考:
Git 工作流程
Git分支管理策略

你可能感兴趣的:(git)