[ git ] 关于制定 gitflow 工作流的思考和总结

git 工作流这个并不是只是前端开发只需要掌握的技能，而是程序员必备技能。它更多的是从项目管理的角度和根据项目的实际情况出发而制定出来的一个开发流程的标准。

有了一个明确的标准，可以避免开发合并时出现的冲突问题和代码事故风险降到最低，在后续迭代的过程中，也容易对之前的代码进行回溯。只要严格按照这个标准执行，整个项目的开发上线流程清晰规范开发者的操作，出现事故的概率也会降低很多。

标准 gitflow 工作流

在一个比较标准的 gitflow ，我认为是包含了几部分的分支代码。

分别是 feature 功能分支, dev 开发分支 ，test 测试分支，release 分支，master 主干，另外一个临时分支 hotfix 热修复分支。

如下图：

master 主干

master 是项目的主干代码，最终代码的合并和 clone 以这个主干为基准，master 的主干的代码只接受 merge request，禁止直接 push 操作。禁止 push 是防止其他在合并时分支的代码没有及时更新导致出现各种严重的冲突，所以，在 master 上 push 是绝对禁止。

release 分支

release ：是项目的发布版本代码，这里分支的代码只接受 meger request ，这个分支在合并之后触发 CI ，实际上就是发布线上的代码。这里为什么是用 release 而不是 master 作为线上版本，最重要的原因就是给项目提供了一个预发布的过程。

1. 假设一个人开发一个功能，开发完在今天发布，这种情况是没有问题的，但如果是一个项目有 10 个人在同时开发，10 个人在今天开发完上线，那么就要上 10 次线。这个显然不合理。所以，多了一个预发布的过程，就可以选择在某个时间点统一合并推送到线上。
2. 最坏的情况下，master 的代码发生了冲突的情况下，保证了线上的代码不会被干扰，虽说这种情况发生的概率比较小，但也可以忽略不考虑。毕竟，即使有冲突也在前面的分支上（dev ， test ）上处理完了。

hotfix 分支

hotfix 分支即紧急修复分支，在遇到有紧急问题需要修复的时候，在 master 上拉出一个临时分支，然后在这个分支上进行修改，修改完之后立即合并回 master 之后上线。

上线之后，确保项目稳定没有其他问题的情况下，需要将这个 hotfix 分支删除，这一步很重要不然后面在从功能分支上修改代码，又有一个人在 hotfix 上修改代码这个时候就会冲突，所以，临时分支一定是改完就删，下一次修改必须是最新代码。

test 测试分支

test 分支，我认为是也是一个比较独立的分支，他和 release 很像，release 是作为线上发布的分支，而 test 是作为测试环境部署的分支，他们都是只接受 merge request 。唯一不同的就是 test 他可以合并到 master 上。但是，这一点争议。

一种说法是：test 按功能来说它是一个作为测试环境发布的分支，那么，也就是说这上面的的代码还不确定能不能够上线发布，因为这个分支上的代码存在了其他的 feature 分支代码，是不确定能够合并到 master 上面的。应该将确定好的代码 从 feature 直接合并到 master ，而 test 仅仅只是一个用来发布CI推送测试环境的分支。

另一种说法是， test 分支可以合并至 master，因为上了测试环境说明功能已经齐全，test 只是给非开发同学进行的体验和测试同学测试，测试通过应该就将整个 test 合并 master ，只要和当前 test 上的 feature分支 的同学确认即可。

个人还是比较倾向前面一种，test 最好不要直接合并 master 。因为，test 分支上有其他 feature ，最好还是不要揉在合并，另一个是，test 一旦出现了什么冲突，可以最简单可以删除重新 branch 。

dev 分支

dev 分支就是开发分支，dev 分支是和 master 保持平行的。开发之前都会更新 dev 分支，再从 dev 分支上拉取 feature 分支。dev 分支在 feature 开发完毕之后 ，合并到开发环境可以进行开发之间的联调。确认无误后同步到 test 分支，在 test 分支上产品和测试都可以进行体验。

同时，如果有微调的地方或者需要修改的地方，开发还是可以在 dev 中进行修改，自测通过之后再同步 test 分支也就是 CI 到测试环境。 这样开发和测试不会相互干扰，如图：

feture 分支

feature 分支就是功能分支，建议是一个模块就拉一条分支。但是，在实际开发中还是要看情况。我的习惯是先对齐发布时间，同个模块同个发布时间的放在一个分支。不然， 10 个模块拉 10个分支最后弄懵的是自己。

简化 gitflow 工作流（推荐）

根据项目的情况而定，如果不是特别大的项目，按照上面的来看是会感觉整个过程有点繁琐。换句话说，是不是就是有没必要搞得这么认真？

有些项目可能不是核心而且维护的同学也是有开发经验的，那这里面是不是可以简化一些流程，这个其实也是可以的。毕竟，如果项目不大，流程却弄得太过标准化，可能维护起来也会浪费一些时间。

不存在 hotfix 分支

hotfix 其实就是一个临时分支，如果从功能上来看，他也就是一个 feature 。那么，在遇到问题的时候可以直接拉一个 feature 改完合并上线。

不存在 dev 分支

dev 实际上是和 master 平行，那么，在一些规模不大的项目中，完全可在本地进行自测和联调，，自测通过之后再推送到 test 分支上。

简化结果

去掉 hotfix 和 dev之后，看起来流程看起来就没有那么的啰嗦。

有 master 的基础上创建 feature 和 hotfix 一样，开发之后同步 test ，test 也是不直接合并到 master，通过测试再发布上线。看上去就是开发，测试，上线一目了然。

超简化 gitflow 工作流

这一种一般就是边缘的一些小项目或者是一小部分祖传代码，1--3个人维护的项目同时彼此也是熟悉 git 操作，那么就可以改完就上。没有 release 和 test 分支。直接就是 一个主干和 feature 分支。

以上就是我在开发和改造旧项目的 gitflow工作流总结。