美文网首页
Git笔记与思考六:工作流

Git笔记与思考六:工作流

作者: 囧书 | 来源:发表于2017-11-15 17:29 被阅读52次

工作流,讲的是对项目版本管理的一套操作流程规范。
在SVN时代,大家别无选择,都是从同一个分支上开发,提交,解决冲突。
用Git做版本管理后,得益于其分布式能力,大家就可以不依赖中央版本库,各自独立开发,提交,再在适当时候合并。因其灵活性而产生了多种多样的工作流。

集中式工作流

当然,你也可以忽略Git的分布式能力,忽略方便快捷的分支控制能力,在Git上用出Svn的感觉,反正你开心就好啦。这种在一个分支上进行协作的方式,我们也给它起个名,就叫集中式工作流。
所有人都在一个分支上开发,优点还是有的:

  1. 简单粗暴易操作,适合不太复杂的小项目
  2. 每一次提交,都解决一次冲突,化大冲突为小冲突。
  3. 当需要依赖他人的工作输出时,或者说与他人工作的耦合度高时,能方便工作快速推进。
    但是缺点也非常明显:
  4. 提交历史混乱,从提交历史上难以追踪一个完整功能的提交情况。
  5. 每次提交都有冲突的可能,假如冲突不好解决,或者合并了他人有问题的代码,就会打断自己的工作节奏。
  6. 不利于code review,不利于代码质量管理

Git Flow

我们应该在一个功能,或者叫特性,开发完成后,才与他人代码进行合并。
这时需要为一个个特性的开发创建专门分支。
在特性分支合并进master后,并不意味着代码就能进行发布,可能需要经过各种测试修改,这时需要再创建一个分支来完成这个步骤,它应介于master与特性分支之间,我们可以把它叫做开发分支develop。
另外,对于线上发行版,如果出现了紧急需要修复的bug,还需要一个分支hotfix来完成bug修复。
基于这些想法,Vincent Driessen同学在多年前提出了一个分支模型A successful Git branching model,详细描述了此种工作流,后人大多把它叫做Git Flow。

A successful Git branching model
  • 主要分支
    • master: 永远处在production-ready状态
    • develop: 最新的下次发布开发状态
  • 支援性分支
    • feature branches: 开发新功能都从develop分支出来,完成后merge回develop
    • release branches: 准备要release的版本,只修bugs。从develop分支出来,完成后merge回master和develop
    • hotfix branches: 等不及release版本必须马上修复线上的问题。从master分支出来,完成后merge回master和develop

概略来讲,就是开发工作在develop分支进行,然后提交到release分支,最后合并到master分支。
git工作流很标准但是使用很复杂。

Github Flow

GitHub Flow是github.com提出的方案,简化成只有一个feature分支和一个master分支。
github有一个pull request功能,多人协作时,在feature分支开发完成后,可以向项目负责人发起pull request,请求项目负责人拉取代码,检阅并合并pull request指定的分支。

Gitlab Flow

Gitlab Flow是gitlab.com提出的方案,觉得git flow太复杂,而github flow又过于简化而不能满足项目开发需求。
它的feature分支可以直接合入master分支,而master就变成了开发主分支。对于持续集成需求,提出从master开出pre-production分支和production分支,pre-production作为一个发布前的缓存,而production就代表了线上运行的版本。

Gitlab Flow 环境分支
你可能会奇怪它为什么有一个发布前缓存,这个看实际应用情景可选。比如iOS应用的发布,有一个苹果审核阶段,这个阶段的代码版本就是预发版本,可放在pre-production中,待审核通过,代码不再修改时,就随着应用的真正发布而同步到production分支。以后当我们需要追溯历史发布版本时,只需要查看production分支就可以了。

同样gitlab也有像github一样的pull request,不过在gitlab中,这个功能叫做merge request,也是请求别人来拉取我的分支代码,code review,然后合并。

一些小Tips

  • 空目录在Git中是个无关对象,它不能通过add命令被添加到提交中。如果需要把空目录提交并push到远程仓库,可以在目录下建一个无关文件.gitkeep
  • 特性分支上的提交如果是比较随意的话,它在合入主开发分支时应压缩一下提交历史,再比较正式地的提交一次。这时可用到squash命令,同时它可以作为merge的选项git merge --squash branch,这样的合并不会产生新提交,需要你在解决完冲突后,自己提交一次。

参考阅读

相关文章

网友评论

      本文标题:Git笔记与思考六:工作流

      本文链接:https://www.haomeiwen.com/subject/mmrhvxtx.html