Gitflow工作流示例
前言
本文演示了如何用Gitflow来管理单个发布循环。
初始化中央仓库
这时,Git会为你默认创建一个master分支,将你的最初的项目代码提交到master分支上。
创建开发分支
从master创建一个develop分支,并将其push到服务器上。并让团队中每个成员都建立该分支的本地拷贝。develop分支将会包含项目的全部历史提交,而master分支可能只包含部分历史提交。
开始开发新功能
Jack需要基于develop分支拉取feature1分支,并在该分支上面进行新功能的开发。
完成新功能开发
Jack提交了所有代码到分支feature1上之后,将feature1分支合并到develop分支,解决冲突并推送到中央仓库。这里需要在合并前确保本地的develop分支是最新的。
发布新功能
Jack确定了发布的版本号为0.1,并且从develop拉了一个发布分支release-0.1,在发布过程中产生的问题都会提交到这个分支上,发布前执行测试和创建release note也都会基于这个分支来做。这里做到了所谓的发布前的代码冻结的作用。
完成发布
Jack完成了0.1版本的发布,并且把release-0.1分支合并到master分支上,同时在master分支上提交了0.1版本的tag。并把master分支合并到develop分支上。
这时,一个新功能的开发和一个新版本的发布已经完成。下面来看一下hotfix的流程。
发现bug并进行hotfix
Jack从master拉取了一个hotfix-issue-001分支,并且对issue-001进行修复。
发布hotfix
Jack发布了hotfix-issue-001分支,并将其合并回master分支。然后再将master分支与develop分支进行合并。
这时,一个hotfix的发布已经完成。
上面所列举的Gitflow的用法只是使用过程中的某种特例,并不是所必须要遵守的规定。我们在使用Gitflow的过程中,需要大胆地对Gitflow的用法做取舍,以满足项目管理的健壮,完备和简洁。
后记
简化
这里提供一种简化Gitflow的思路,适用于小型开发团队。master分支与develop分支可以在同时开发的功能较少时进行简化,只使用master分支,略去develop分支。feature分支与release分支可以在开发人员较少时进行简化,只使用feature分支,略去release分支。
扩展
- 在并行开发的功能较多时,需要特别为发布计划和代码merge建立管理制度,以防止不同的功能之间冲突过多而花费大量时间。
- 在开发人员较多时,可以采用在feature分支的基础上在拉取类似于feature-jack的个人开发分支,以减少开发过程中的冲突。
- 针对有较为严格code review规定的团队,可以采用pull request来进行code review。
- 所有的团队都需要注意,定时清理不需要的分支。
- 所有的团队都需要注意,需要制定严格的分支名称的规则。