自从2018.04.24从原公司离职以后，工作上倒比以前忙多了！朋友新公司属于创业公司，项目代码也是用git管理，但git的很多优点（特别是分支功能）并没有用上。

单分支的问题

• 多人开发时，有人提交了可能不能运行的代码，导致整个团队开发无法进行，人越多越容易出现问题；
• 突发bug无法定位麻烦，得去找标签，而有时候有人发布却忘记打标签，只能按时间大概查找；
• 开发一个功能时又有新功能必须立即开发，切换困难；
• 无法自动发布，无法nightly build；
• 只有一个分支，版本提交混乱，无主次；
• 无法做代码审查

单个分支基本上也就做了代码备份功能了，除非是一个人比较简单的开发，都不建议用单个分支管理代码。

GitFlow

从2013年用git做代码管理，在这几年也碰到过各种问题，逐渐形成一套比较成熟的适合中小型团队的git管理模式。这里说的管理模式其实就是GitFlow，说其比较成熟是因为我在多个团队使用过，流程比较清晰，实践验证有比较好的效果。

我们先看一下GitFlow工作流，这个图是GitFlow描述得最清晰的图了：

分支：

• master 稳定分支，随时可以发布，可支持自动发布
• develop 不直接在此分支上开发，从feature分支合并
• feature 功能/特性分支，每个功能点单独创建，可多人在同一feature分支上开发
• hotfix 紧急修补分支，用在上线后出现紧急bug时
• release 可以看做是测试分支，版本提测后在此分支上修改bug，其它分支可以继续新功能

实际应用

GitFlow这个工作流不是死的，在不同项目中根据需要调整。例如以前有个手游项目因为有iPhone、Android不同系统版本，每个系统版本还有很多不同渠道，在一些时间段需求上还有多个功能版本要求同时进行，这种情况就得灵活变通了，但是大的工作流是相似的。

根据现有项目和人员情况，我们简化了一下GitFlow工作流，把develop和release分支合并为一个分支，减少分支合并，因为项目还在开发阶段，测试团队是跟着开发节奏进行测试的，并没有完整的测试规范，也还没到要求测试版本除修改bug不能有任何其它代码修改的程度。

但这一块在后期还是得注意，防止测试版本被开发人员任意修改，导致测试无法达到预期结果，产品质量无法保证。现在简化的方案就是如果有一些功能测试要减少其它功能开发带来的影响，可以在develop版本新建分支进行测试，完成后再合并回develop分支。

原则

• 永远不要在master分支上做开发
• 功能点开发必须从develop分支新建feature分支
• 提交注释必须写明修改内容
• 发布必须打标签

具体Git命令就不列了，主要是要遵循这个思想，很多其它事情也是这样！

---

感谢您阅读 @chaimyu 的帖子，期待您能留言交流！