这是我参与「第三届青训营 -后端场」笔记创作活动的第3篇笔记

0.概述

本文章记录了青训营课程「Git 的正确使用姿势与最佳实践」中的部分笔记

笔记要点：git的工作流与使用建议

• 1.常见问题

• •   1.在Gerrit平台上使用Merge的方式合入代码

• Gerrit是集中式工作流，不推荐使用merge方式合入代码，应该是在主干分支开发后，直接Push

• •   2.不了解保护分支，Code Review, Cl 等概念，研发流程不规范

  •    保护分支：防止用户直接向主干分支提交代码，必须通过PR来进行合入。

• Code Review,Cl:都是在合入前的检查策略，Code Review是人工进行检查，Cl则是通过一些定制化的脚本来进行一些校验。

• •   3.代码历史混乱，代码合并方式不清晰

不理解Fast Forward和Three Way Merge的区别，本地代码更新频繁的使用Three Way的方式，导致生成过多的Merge节点，使提交历史变得复杂不清晰。

2.不同的工作流

1. 简要比较

• 1.1 集中式工作流

• • 代表平台： Gerrit、SVN
  • 特点：仅依托于主干分支进行开发，不存在其他分支
  • 合入方式：Fast-forward

• 1.2 分支管理工作流

• • 代表平台：Gerrit、Gitlab
  • 特点： 可以定义不同特性的开发分支，上线分支，在开发分支完成开发后再通过MR / PR 合入主干分支
  • 合入方式：自定义，Fast-forward or Tree-Way Merge

2. 集中式工作流

• 仅依托于master分支进行研发活动

• •   工作方式- 获取远端master代码- 直接在master分支完成修改- 提交前拉取最新的master代码和本地代码进行合并（使用rebase），若有冲突则解决冲突- 提交本地代码到master

  •   代表产品：Gerrit

简要描述：Gerrit是由Google开发的一款代码托管平台，主要的特点就是能够很好的进行代码评审。在aosp(android open source project)中使用的很广，Gerrit的开发流程就是一种集中式工作流。

• 基本原理
• • 依托于Change ID概念，每个提交生成一个单独的代码评审。
  • 提交上去的代码不会存储在真正的refs/heads/下的分支中，而是存在一个refs/for/的引用下。
  • 通过refs/meta/config下的文件存储代码的配置，包括权限，评审等配置，每个Change都必须要完成Review后才能合入。

• 优点
• • 提供强制的代码评审机制，保证代码的质量
  • 提供更丰富的权限功能，可以针对分支做细粒度的权限管控
  • 保证master的历史整洁性
  • Aosp多仓的场景支持更好

• 缺点
• • 开发人员较多的情况下，更容易出现冲突
  • 对于多分支的支持较差，想要区分多个版本的线上代码时，更容易出现问题
  • 一般只有管理员才能创建仓库，比较难以在项目之间形成代码复用，比如类似的fo水操作就不支持。

• 3. 分支管理工作流

• •   代表产品：Git Flow

简要描述：分支类型丰富，规范严格

• 五种类型分支
• • Master 主干分支
  • Develop 开发分支
  • Feature 特性分支
  • Release 发布分支
  • Hotfix 热修复分支

优点 ：若能按照定义严格执行，代码会很清晰，且难以出现混乱

• 缺点：流程过于复杂，上线节奏会比较慢。由于太复杂，研发容易不按标准执行，从而导致代码混乱

• •   代表产品：Github Flow

  •   简要描述：只有主干分支和开发分支，规则简单
  •   团队合作方式
  • owner 创建好仓库后，其他用户通过fork方式来创建自己的仓库，并在fork的仓库上进行开发
  • owner 创建好仓库后，统一给团队内成员分配权限，直接在同一仓库内进行开发

  •   代表产品：GItlab Flow

  •   简要描述：在主干分支和开发分支之上构建环境分支，版本分支，满足不同发布或环境的需要
  •   原则：upstream first 上游优先
  •   只有在上游分支采纳的代码才可以进入到下游分支，一般上游分支就是master

• 3. 代码合并

• •   1.Fast-Forward

  •   不会产生一个merge节点，合并后保持一个线性历史，如果target分支有了更新，则需要通过rebase操作更新source branch后才可以合入

  •   2.Three-Way Merge

  •   三方合并，会产生一个新的merge结点

4. 如何选择合适的工作流

选择原则：没有最好的，只有最合适的

针对小型团队合作，推荐使用Github工作流即可

使用原则：

1.尽量保证少量多次，最好不要一次性提交上千行代码

2.提交Pull Request后最少需要保证有代码审查后再合入

3.主干分支尽量保持整洁，使用fast-forward合入方式，合入前进行rebase

5.总结

如何使用好git对于团队开发来说非常重要，熟悉git的开发流程能够帮助提升团队开发效率，最重要的是：选择最合适的git工作流。

思维导图：