1.为什么需要统一git分支管理？
在使用Git管理代码以及多人协作的开发模式下，一个团队甚至一个公司对Git的使用有统一规范的工作流程尤为重要，开发团队遵循统一的规则执行功能开发，问题修复，分支合并，版本迭代及发布等操作，可以使团队合作变得平滑顺畅，项目有序向前推进
2.团队目前git分支管理现状？
主分支master（经常没有合并）
Develop（开发分支）
v1 v2...(不同的版本有时候有的特殊版本就另开一个分支)
Member（个人命名的分支）
综上 并没有一套规范的方案
3.市面常见的方案？
3.1.TBD(Trunk based Development)
主干开发 ，是一套代码分支管理策略，开发人员之间通过约定向被指定为 主干 的分支提交代码，以此抵抗因为长期存在的多分支导致的开发压力。此举可 避免分支合并的困扰，保证随时拥有可发布的版本
优点：简单粗暴 没有了分支的代码隔离 测试和解决冲突都变得简单 便于持续集成
缺点：多版本并行开发需要引入FeatureToggle 以及大量测试覆盖反复集成
3.2.Git flow
GitFlow 模式是若干模式的集大成者，包含一个主干分支、一个开发分支、许多的特性分支、许多的发布分支和 Hotfix 分支，以及许多繁琐的合并规则
Git flow需要同时维护两个甚至更多分支，Hotfix分支从master创建，Release和Feature分支从develop创建，工作完成后又需要将代码合并回 develop 和 master。
优点：流程清晰，分支管理严格（适用于发布周期比较长的“版本发布”）
缺点：在实际应用中，很多开发者会忘记合并回 develop 或者 master，并且各辅助分支之间互相独立，如果从master上pull代码不够及时，一方面可能造成某个分支长期使用已经过时或者错误的代码，另一方面如果与master相隔较远，合并分支时可能会有大量代码冲突，往往需要花费很多时间来消除代码冲突，并且非常容易出错，影响项目的持续集成
3.3. GitHub flow
这种策略无非是在 TBD的基础上，增加了个人仓库和 Pull Request 合并代码的操作，与在同一个仓库里增加个人分支的做法类似，从实用的意义来说，它更合适分布式团队
优点：适合敏捷开发（简单方便）
缺点：多个环境下的产品部署，多个版本的发布或问题修复，只有一个master便会显得力不从心
3.4.阿里的AoneFlow
AoneFlow 只使用三种分支类型：主干分支、特性分支、发布分支，以及三条基本规则
开始工作前，从主干创建特性分支=》 通过合并特性分支，形成发布分支 =》发布到线上正式环境后，合并相应的发布分支到主干，在主干添加标签，同时删除该发布分支关联的特性分支
4.团队git方案思考？
个人建议结合 GitHub flow和AoneFlow方案
开始工作前，从主干创建个人分支=》 通过合并个人分支，形成发布分支 =》发布到线上正式环境后，合并相应的发布分支到主干，在主干添加标签
不使用特性分支 是因为一个特性分支对应一个需求 可能一个需求是多人合作 而我们团队基本一个项目只有一两人参与开发 不需要那么细致区分 同时特性分支对整体流程要求较高 有时候只是修复简单的bug而已 又需要增加hotfix分支 实在太麻烦 在开发过程中我们可以把hotfix和feature合并为个人member分支 发布分支relesse保证多版本并行开发 例如我们有v1 v2 test prod等版本 都可以对应release版本提交 master主分支保证了随时可发布的稳定版本 开发人员个人仓库提交到release版本的代码需要管理员进行代码review才可合并
5.Code review必要性
Code Review不只是一种管理方法，也是开发者特有的沟通方式，更是一种团队文化。主要目的是保障我们的代码质量和软件产品质量的同时提高团队整体技术实力，共同成长。Code Review机制是否健全是评价一个研发团队技术氛围好坏的重要参考。
6.Code Review文化
通过多层次的Code Review体系，在团队中建立起集体认知：
- 代码是团队共有的知识财富，而不是个人的私有地
- 所有人对所有代码的最终质量负责，而非某个人对某些代码负责
- 完成功能只是开始，代码需要持续改进以符合团队标准
Code Review对于团队中的新人来说是很好的锻炼机会，我们团队的新人首次提交代码，被打回更新四五次是很正常的事情。集体对代码质量的追求，也能提升新人的成就感、荣誉感。
7.Code review注意事项（规范 心态）
不要刻意的去寻找代码bug
不要按照自己的编程风格去评论别人的代码（按照约定好的规范）
不要带着抨击和质疑别人能力的心态去进行代码评审
不要在不确定的问题上争来争去
不要听不进别人的意见
参与者最好不要自己都没想明白就提意见
8.团队如何进行代码review
前期建议指定项目负责人进行代码提交的审核 落实团队代码规范（配合gitlab的PR）
规范熟悉之后建议轮流互相review 但是不可流于形式（减轻负责人压力）
形成习惯之后 争取从管理制度变成团队文化 每个月进行review记录分享
