高效利用一次蹲坑时间,看看如何使用Git Flow进行高效开发,什么才是Git提交的正确姿势,怎样使用GitLab进行Code Review:
使用Git Flow高效开发;
Git提交正确姿势,Commit message编写指南;
使用GitLab进行团队内的Code Review;
使用Git Flow进行高效开发
在工作环境中,绕不开效率一词,由于任何一次版本迭代,几乎都是需要整个团队协作的,所以,高效开发不仅仅是个人效率问题,还涉及到整个团队的协作效率。个人开发,可以怎么顺手怎么搞,怎么开心怎么玩,但在团队里协作的时候,只一个人顺手开心是不够,还需要整个团队协作高效。提高效率,一般我们会这么搞:
遵守行业内的最佳实践;
借助工具自动遵循规范;
什么是Git Flow?
Git Flow是构建在Git之上的一个组织软件开发活动的模型,是在Git之上构建的一项软件开发最佳实践。Git Flow是一套使用Git进行源代码管理时的一套行为规范和简化部分Git操作的工具,一篇名为A successful Git branching model的博文介绍了一种在Git之上的软件开发模型。通过利用Git创建和管理分支的能力,为每个分支设定具有特定的含义名称,并将软件生命周期中的各类活动归并到不同的分支上。实现了软件开发过程不同操作的相互隔离。这种软件开发的活动模型被称为Git Flow。
Git Flow备忘清
Git Flow是一个Git扩展集,按Vincent Driessen的分支模型提供高层次的库操作, 这个备忘清单展示了Git Flow的基本操作和效果。
Git Flow介绍
Git Flow常用的分支:master, develop, feature, hotfix, release;
历史分支(master , develop): 相对使用仅有的一个master分支,Gitflow工作流使用2个分支来记录项目的历史。master分支存储了正式发布的历史,而develop分支作为功能的集成分支。 这样也方便master分支上的所有提交分配一个版本号;
功能分支(Feature): 每个新功能位于一个自己的分支,这样可以push到中央仓库以备份和协作。 但功能分支不是从master分支上拉出新分支,而是使用develop分支作为父分支。当新功能完成时,合并回develop分支。 新功能提交应该从不直接与master分支交互;
发布分支(release): 一旦develop分支上有了做一次发布(或者说快到了既定的发布日)的足够功能,就从develop分支上fork一个发布分支。 新建的分支用于开始发布循环,所以从这个时间点开始之后新的功能不能再加到这个分支上—— 这个分支只应该做Bug修复、文档生成和其它面向发布任务。 一旦对外发布的工作都完成了,发布分支合并到master分支并分配一个版本号打好Tag。 另外,这些从新建发布分支以来的做的修改要合并回develop分支;
维护分支(hotfix): 维护分支或说是热修复(hotfix