Git 的研发流程

团队合作中git如何使用的

常见问题

在Gerrit平台上使用merge的方式合并代码

答：集中式工作流，不推荐使用merge,应该是主干分支开发后，整洁push

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

答：保护分支，防止用户直接向主干分支提交代码，必须通过Pull request来合入

Code Review,Cl :都是合入前的检查策略，CR：人工检查，CI：定制化的脚本进行校验

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

答：不了解 Fast Forward和Three Way Merge的区别，本地频繁使用Three Way的方式，导致生成过多的Merge节点，使提交历史变复杂。

分支管理工作流

1. Git Flow(早期)

五种类型分支

Master: 主干分支

Develop：开发分支

Feature：特性分支

Release：发布分支

Hotfix：热修复分支

优点

标准执行严格，代码会很清晰，不出混乱

缺点

流程复杂，上线节奏慢，复杂，容易不按照标准执行，出现代码混乱

2. GitHub Flow

只有一个主干分支，基于pull request往主干分支中提交代码。

选择团队合作的方式

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

分支管理工作

创建 Pull request

创建主分支 main

创建 feature 分支

然后就可以创建一个 feature 到main的 pull request

对分支进行保护设置

限制合入的策略；限制直接push操作。

3. Gitlab Flow

对GitFlow 和Github Flow 做出优化，保持了单一主分支，又可以适应不同开发环境。

原则 : upstream first 上游优先

上游分支就是master

代码合并

Fast-Forward

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

# 切换到合并的主分支
git merge 被合并的分支明(test) --ff-only

Three-Way Merge

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

git merge 被合并的分支明(test) --no-ff

如何选择合适的工作流

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

小型团队：推荐GitHub 工作流

尽量保证少量多次，最好不要一次性提交上千行代码
提交 Pull Request 后最少需要保证有CR(代码审核)
主干分支尽量保持整洁，使用fast-forward合入方式，合入前进行rebase

rebase会把你当前分支的 commit 放到公共分支的最后面,所以叫变基。就好像你从公共分支又重新拉出来这个分支一样。举例:如果你从 master 拉了个feature分支出来,然后你提交了几个 commit,这个时候刚好有人把他开发的东西合并到 master 了,这个时候 master 就比你拉分支的时候多了几个 commit,如果这个时候你 rebase master 的话，就会把你当前的几个 commit，放到那个人 commit 的后面。

merge和rebase实际上只是用的场景不一样

比如rebase,你自己开发分支一直在做,然后某一天，你想把主线的修改合到你的分支上,做一次集成,这种情况就用rebase比较好.把你的提交都放在主线修改的头上

git rebase -i master

merge 会把公共分支和你当前的commit 合并在一起，形成一个新的 commit 提交

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