Git Flow
Git 的一大特点就是可以创建很多分支并行开发。正因为它的灵活性,团队中如果没有一个成熟的分支模型的话,那将会是一团糟。
有个很成熟的叫 Git Flow 的分支模型,它能够应对 99% 的场景,剩下的那 1% 留给几乎不存在的极度变态的场景。
需要注意的是,它只是一个模型,而不是一个工具;你可以用工具去应用这个模型,也可以用最朴实的命令行。所以,重要的是理解概念,不要执着于实行的手段。
简单说来,Git Flow 就是给原本普普通通的分支赋予了不同的「职责」:
- master——最为稳定功能最为完整的随时可发布的代码;
- hotfix——修复线上代码的 bug;
- develop——永远是功能最新最全的分支;
- feature——某个功能点正在开发阶段;
- release——发布定期要上线的功能。
看到上面的「master」和「develop」加粗了吧?代表它们是「主要分支」,其他的分支是基于它们派生出来的。主要分支每种类型只能有一个,派生分支每个类型可以同时存在多个。各类型分支之间的关系用一张图来体现就是:
开发功能
在确定发布日期之后,将需要完成的内容细分一下分配出去,负责某个功能的开发人员利用 SourceTree 所提供的 Git Flow 工具创建一个对应的 feature 分支。如果是多人配合的话,创建分支并做一些初始化工作之后就推送创建远程分支;否则,直到功能开发完毕要合并进 develop 前,不要创建远程分支。
功能开发完并自测之后,先切换到 develop 分支将最新的代码拉取下来,再切换回自己负责的 feature 分支把 develop 分支的代码合并进来。合并方式参照上文中的「合并」,如果有冲突则自己和配合的人一起解决。
然后,到 GitLab 上的项目首页创建合并请求(merge request)。
「来源分支」选择要被合并的 feature 分支且「目标分支」选择 develop 分支后点击「比较分支」按钮,在出现的表单中将处理人指派为项目负责人。
项目负责人在收到合并请求时,应该先做下代码审核看看有没有明显的严重的错误;有问题就找负责开发的人去修改,没有就接受请求并删除对应的 feature 分支。
在将某次发布的所需功能全部开发完成时,就可以交付测试了。
测试功能
负责测试的人创建一个 release 分支部署到测试环境进行测试;若发现了 bug,相应的开发人员就在 release 分支上或者基于 release 分支创建一个分支进行修复。
发布上线
当确保某次发布的功能可以发布时,负责发布的人将 release 分支合并进 master 和 develop 并打上 tag,然后打包发布到线上环境。
建议打 tag 时在信息中详细描述这次发布的内容,如:添加了哪些功能,修复了什么问题。
修复问题
当发现线上环境的代码有小问题或者做些文案修改时,相关开发人员就在本地创建 hotfix 分支进行修改,具体操作参考「开发功能」。
如果是相当严重的问题,可能就得回滚到上一个 tag 的版本了。