小团队Git工作流应用
因为各种原因一晃两年没来了，帐户价值也少了很多，不知道steem的朋友们还在不在？
两年前写过一篇中小型开发团队的Git工作流应用，最近在新公司继续培训一下Gitflow流程，过了一下原文章，新瓶装旧酒，简单修改了以前文章，并补了一张Gitflow简易流程图。
单分支的问题
- 多人开发时，有人提交了运行不正常或者无法运行的代码，导致整个团队开发无法进行，人越多越容易出现问题；
- 突发bug无法准确定位，而有时候开发人员发布却忘记打标签，只能按时间大概查找，在同一时间周期内提交比较多时，无法精确定位；
- 开发一个功能时又有新功能必须立即开发，切换困难；
- 无法自动发布，无法nightly build；
- 只有一个分支，版本提交混乱，无主次；
- 无法做代码审查
单个分支基本上也就做了代码备份功能了，除非是一个人比较简单的开发，都不建议用单个分支管理代码。
GitFlow
从2013年用git做代码管理，在这几年也碰到过各种问题，逐渐形成一套比较成熟的适合中小型团队的git管理模式。这里说的管理模式其实就是GitFlow，说其比较成熟是因为我在多个团队使用过，流程比较清晰，实践验证有比较好的效果。
我们先看一下GitFlow工作流，这个图是GitFlow描述得最清晰的图了：
分支说明：
- master 稳定分支，随时可以发布，可支持自动发布
- develop 一般不直接在此分支上开发，从feature分支合并
- feature 功能/特性分支，每个功能点单独创建，可多人在同一feature分支上开发
- hotfix 紧急修补分支，用在上线后出现紧急bug时
- release 可以看做是测试分支，版本提测后在此分支上修改bug，其它分支可以继续新功能
实际应用
GitFlow这个工作流不是死的，在不同项目中根据需要调整。例如以前有个手游项目因为有iPhone、Android不同系统版本，每个系统版本还有很多不同渠道，在一些时间段需求上还有多个功能版本要求同时进行，这种情况就得灵活变通了，但是大的工作流是相似的。
我们现在以开发一款小游戏来看整个git流程：
- 初始分支，master分支，从master分支新建develop分支
- 开发人员A，签出develop分支，搭建框架，提交到develop分支
- 开发人员A，负责游戏逻辑编写，从develop新建分支features/logic，进行开发
- 开发人员B，负责界面UI编写，从develop新建分支features/ui，进行开发
- 开发人员A，逻辑编写完成，合并到develop分支
- 开发人员B，界面缩写完成，合并到develop分支
- 合并后develop分支可进行测试，修改bug可以develop分支上进行，比较大的修改建议新建分支
- 测试完成，develop分支合并到master分支，并在master分支上打标签版本1.0.0
- 开发人员A、B继续从develop分支新建分支开发新版本功能，此时线上版本发现bug，开发人员从master分支新建hotfix分支，修改bug并测试通过后，合并到master分支，并打版本标签1.0.1，同时将hotfix合并到develop分支。
根据现有项目和人员情况，我们简化了一下GitFlow工作流，把develop和release分支合并为一个分支，减少分支合并，因为项目还在开发阶段，测试团队是跟着开发节奏进行测试的，并没有完整的测试规范，也还没到要求测试版本除修改bug不能有任何其它代码修改的程度。
但这一块在后期还是得注意，防止测试版本被开发人员任意修改，导致测试无法达到预期结果，产品质量无法保证。现在简化的方案就是如果有一些功能测试要减少其它功能开发带来的影响，可以在develop版本新建分支进行测试，完成后再合并回develop分支。
原则
- 永远不要在master分支上做开发
- 功能点开发必须从develop分支新建feature分支
- 提交注释必须写明修改内容
- 发布必须打标签
感谢您阅读 @chaimyu 的帖子，期待您能留言交流！