Git最佳实践-Git flow_git流提交

Git分支管理背景

Git是当下最流行的版本管理系统，阮一峰在自己的博文中提到过：“如果你严肃对待编程，就必定会使用版本管理工具”。Git操作是基于分支的，当下环境衍生出多种优秀的分支管理策略，其目的就是要保证不同分支各司其职，避免多人协作过程中代码冲突、代码版本出现问题。在日常迭代过程中，每个公司都有一套自己的分支管理规范，但万变不离其宗，都有Vincent Driessen提出的Git flow方法的影子。

Git flow关键分支

基于Git flow方法协作提交代码时，一般是基于一下分支：

以下是Git flow流程图：

master与develop

这张图涉及内容较多，我们只需要关注两个分支，一个是master分支，另一个是develop分支，通过箭头可以看到，develop分支是基于master分支创建，在提交代码后，又重新回到了master分支，这里体现的是，在迭代开始前，需要基于线上代码最新版本合并到开发分支，作为团队成员开发的公共分支。在使用Git时，需要遵循一个原则：从哪里来，最后回到哪里去。

develop与feature

接下来我们需要关注的是feature分支与develop分支。在团队协作过程中，对于需求的开发，通常是采用一个成员负责一个功能点或者模块，那么就需要不同成员往develop分支提交代码，即需要从develop分支创建feature分支开发新功能，编码自测完成后，再从feature分支push（推送）到develop分支，这同样遵循了以上规则。

develop与release

在企业开发中，每次迭代往往定义一个版本号，release分支与之对应。随时间线推进，到达迭代开发中的提测阶段，则需要将开发的新代码从develop分支推送到release分支，而后发布代码(CI/CD)到测试环境供测试验证。

release与bugfix

当测试提出缺陷时，似乎我们需要排查一下自己代码中是否存在问题。如果是，那么我们需要基于测试环境的release分支代码版本做修改，此时，我建议基于release分支去创建一个bugfix分支用于修复代码中的问题。修复完毕后再将bugfix分支的代码推送到release分支，push完成后，将bugfix分支删除，确保一个bugfix分支只做一件事。

注意：在合并前需要确保release分支代码是最新版本，建议在push到其他分支前update一下分支到最新版本，因为不止你一个可怜人在修复Bug。

如果你所在的公司使用Git flow的标准流程。develop分支承担了两个“角色”：“写Bug”和“改Bug”。则同样可以从release分支更新最新代码后，将release分支代码merge(合并)到develop分支。再基于develop分支修改代码，push到develop，而后切换到release分支，更新到最新版本，merge develop分支到release分支即可。

release与master

测试完成、熬到上线、喜大普奔。上线时需要将release分支代码推送到master，同样的道理，在推送前需要将master分支代码更新到最新版本，release分支合并master分支代码，再切换到master分支合并release分支代码。

上线时需要整理迭代涉及的配置项更新、迭代变更SQL脚本、历史数据处理数据SQL脚本、静态资源等整理出来，发布执行到线上环境，此过程不在本文中赘述。

master与hotfix

紧急！震惊！线上代码失去公信力了吗？

当生产环境用户反馈了一个问题，确认为代码缺陷时，需要基于最新的master分支创建hotfix分支去修复线上bug，修复完毕后，从hotfix分支按上述release分支推送到master分支流程推送代码到master分支即可。

为什么在merge其他分支前，需保证其他分支代码为最新版本？

你并不能确定目标分支代码是否有变更。

1. 一个工程可能有多个团队维护、推送代码，你并不知道其他团队什么时间、推送了什么内容到分支。
2. 在不同迭代版本时间线上，可能有一些线上bug的维护。

如何使用Git flow

1. 命令行
2. 编码工具自带Git客户端，如IDEA
3. sourceTree
4. …

最后

提高团队协作效率，人人有责。