Git 的研发流程 | 青训营笔记

常见问题：

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

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

2.不了解保护分支，Code Review ，CI 等概念，研发流程补规范。

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

Code Review，CI:都是在合入前的检查策略，Code Review是人工进行检查，Cl则是通过一些定制化

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

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

不同的工作流：

集中式工作流

什么是集中式工作流？

只依托于 master 分支进行研发活动。

工作方式：

1. 获取远端 master 代码。
2. 直接 master 分支完成修改。
3. 提交前拉取最新的 master 代码和本地代码进行合并（使用 rebase），如果有冲突需要解决冲突。
4. 提交本地代码到 master

集中式工作流--Gerrit

Gerrit 是由 Google 开发的一款代码托管平台，主要的特点就是能够很好的进行代码评审。

在 asop （android open source project）中使用的很广，Gerrit 的开发流程就是一种集中式工作流。

基本原理

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

优点：

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

缺点：

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

分支管理工作流

Git Flow

Github Flow

Github 的工作流，只有一个主干分支，基于 Pull Request 往主干分支中提交代码。

选择团队合作的方式

1. owner 创建好仓库后，其他用户通过 Fork 的方式来创建自己的仓库，并在 fork 的仓库上进行开发。
2. owner 创建好仓库后，统一给团队成员分配权限，直接在同一个仓库内进行开发。

可以在 Pull Request页面执行C/ CA/ CR等操作，都检查通过后，执行合入。

可以通过进行一些保护分支设置，来限制合入的策略，以及限制直接的push 操作。

Gitlab Flow

Gitlab 推荐的工作流是在GitFlow 和Github Flow 上做出优化，既保持了单一主分支的简便 ，又可以适应不同的开发环境。

原则: upstream first 上游优先

只有在上游分支采纳的代码才可以进入到下游分支，一般上游分支就是master.

代码合并

Fast-Forward

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

Three-Way Merge

三方合并，会产生一个新的merge节点。

如何选择合适的工作流

选择原则

没有最好的，只有最合适的。

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

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

2.提交Pull Request后最少需要保证有CR后再合入。

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

大型团队合作，根据自己的需要指定不同的工作流，不需要局限在某种流程中。