![0f5a95198b45f3825bc2f8e28e16af4f.png](https://i-blog.csdnimg.cn/blog_migrate/86a2ada0181fc5c72262112d1bdbda12.jpeg)
没有规矩不成方圆,如果一个项目只有你一个人在维护,那么你不需要担心很多问题,因为你对它心知肚明,但同时一个人的力量无法支撑起来大型项目。更多时候,我们需要与其他人合作,共同把项目推进,这意味着我们需要牺牲彼此的一些“自由”,在一些约束框架下进行合作,这就是我今天要提到的工作流。
目前比较流行的工作流规范有:
- github-flow
- gitlab-flow
- git-flow
时间线:git-flow --> github-flow --> gitlab-flow
GitHub-Flow
GitHub flow is a lightweight, branch-based workflow that supports teams and projects where deployments are made regularly.
GitHub flow 是轻量级的、基于分支的工作流,它支持团队和项目去进行定期的部署。
![a5b4f751d355cf62a70c18f3e27e4e26.png](https://i-blog.csdnimg.cn/blog_migrate/a9fd9c9c06b47fb90150dd2755142bb6.png)
我所在的项目组使用的就是GHF(GitHub-Flow),我对它比较熟悉。
GHF的思路很简单,很适合大部分项目组。基本可以用下面一张图来表示:
master --> branch --> pull request --> master
GHF追求的是发散性思维,项目任何时候都可以基于当前的主干创建新的特性分支(feature-branch)去开发,最后合并回主干。周而复始。这个思路很适合开源项目,因为每天都会有不同地区的人去维护一个开源项目,通过GHF,大家都可以把自己的想法实现出来,并请求合并到主干,或者开源项目的负责人会按计划确定项目的下一个新特性,来自世界各地的人都可以在特性分支上贡献自己的一份力量。
所以GHF有一个核心要求,就是主干master必须要永远是可运行、可部署状态。这是很合理的,所以没有经过测试或未通过测试的代码是不允许合并到主干的。以前的做法是,针对每一个pull request,项目主要维护者都需要拉取特性分支到本地进行测试,但是现在可以借助CI/CD来自动化完成这一项任务。
优点:
- 简洁,思路很清晰,只有一个master分支和多个feature分支
- 以部署为中心,保证每一个特性分支都可以正常运行
- 支持快速迭代,快速部署,适合需求变化多端的前端项目
工作经验
我所从事的前端项目组常常是同时几个人在开发不同的需求,所以常常是不同的需求对应不同的特性分支,经过开发阶段、体验阶段、测试阶段,最后合并到主干master,再由构建平台基于主干构建出静态资源,最后打包部署到CDN。似乎和GHF不谋而合。
下面是我的一些工作经验总结:
- 主干master必须是可部署状态,避免下一个特性分支是不可运行的状态
- 每一个合并回主干的特性分支也必须是可部署状态
- 多人合作是无法避免冲突,所以遇到冲突的时候,切换到特性分支,然后merge origin master分支,解决完冲突后再次请求合并到主干
- 每一个特性分支经过测试后都可以合并到主干,合并到主干后都可以被删除掉,而且建议删除掉,这样确保项目的分支尽可能简洁,不需要顾虑这个特性分支以后还有没有用
- 项目部署到线上并不意味着结束,一些意想不到的bug还是会发生的,这个时候并不需要也不推荐在之前的特性分支上修复这个bug,可以新建一个修复分支,你可以取名为fix/xxx之类的,按照团队规范来就好,然后快速修复这个bug并重新部署到线上
- 修改公共基础库和修复bug的分支请求合并到主干,都需要另一个开发者来review代码,这样可以尽可能减少“翻车”事件
我们需要确定一件事,就是我们所做的一切都是为了效率,我是指团队效率,而不仅仅是个人效率。而引入GHF,可以帮我们隔离团队里不同维度的代码,减少代码摩擦。工程化的目的就是隔离变化,沉淀共识。
GitLab-Flow
GitLab-Flow可以算是GitHub-Flow的一个升级版,在原有的逻辑上,多了两个分支,Pre-Production分支和Production分支。
![bee4792bbe72d710d4b8d41803000931.png](https://i-blog.csdnimg.cn/blog_migrate/5b7487e11e20cfce7adece9f204cb110.png)
GitHub-Flow适用于线上版本和master版本一致的情况,换句话说,它是基于master分支“持续发布”的,任何需要快速迭代的场景都适合,比如前端和后端,都可以开发新功能或者修复bug后合并到主干,然后走构建发布流程就可以同步到线上了,这很方便。
但是对于移动端来说,就不一样了,因为app发布是需要审核周期的,为了让项目继续向前推进,我们需要另外的分支来应付审核周期。master分支继续跟随需求,而“发布”分支对应每一次上线,可以保证master即使新合并了特性不会影响到“发布”分支。
Git-Flow
Git-Flow算是最早出现的工作流,它包含了项目完整的生命周期,更严谨,当然也相对复杂了一些。可以用一张图来辅助说明:
![71fc7d835d0703fbbd51e9d133f1c207.png](https://i-blog.csdnimg.cn/blog_migrate/eb074f8958e06236778ca2f81b747855.jpeg)
它基于两个长期存在的分支:
- master,具有多个tag,是develop分支上经过开发、测试后稳定发布的版本,用于发布
- develop,是自动构建分支,所有的feature分支的代码完成后会合并到develop
其他三个分支,在完成任务后会被删除:
- feature branches,从develop拉取,为即将发布的版本开发新功能,最终合并回develop
- hotfix,从master拉取,以便快速修复线上问题,修复完成后合并到develop和master
- release branches,从develop拉取,包含所有新功能和必要的修复,并且是彻底测试过的,会合并到master和develop
比较适合客户端开发。Git-Flow不仅是一套规范,也是一套工具,目前流行的是avh版本的git-flow。
参考:
GitHub Flowguides.github.com gitflow & github flow & gitlab flowjuejin.im GitLab Flowabout.gitlab.com 4 branching workflows for Gitmedium.com 嘟嘟:Git flow Github flow Gitlab flow 抽象模型zhuanlan.zhihu.com