基于rebase工作流分支策略实践 – 汪明鑫的个人博客

简单介绍TBD

Trunk-Based-Deployment工作流

基于master分支开发，不引入其他功能分支

目前我们长期处于这种开发模式

基于master分支开发小步快走，爽的一批，不需要各种切分支合分支之类的多余操作，实践起来相当简单，git日志清晰明了。

但是也会需要一定的条件和门槛才会让落地的姿势更优雅，否则也可能会出现各种各样的问题。

落地条件 = 保证代码质量 + 严格code review 机制 + 完善的开关系统。

由于代码是直接推到master的，开发人员需要保证代码质量，组内同事需要进行严格的code review, 核心逻辑变更一定要加开关。

但是随着后期开发人员逐渐增多，需求迭代增多，单分支开发逐渐出现一些问题和阻塞。

代码冲突增多，一人的提交的代码有问题阻塞其他人等等。。。

新的分支开发策略势在必行！

基于rebase的工作流

引入feature功能分支开发模式

简单总结下流程：

1、开发前

拉新分支

2、开发中

在功能分支提commit
每天git rebase master, 解冲突，git push -f
通知项目其他成员拉最新代码

3、测试

独立部署功能分支，完成CI/CD

4、上线

合master git merge feature/xxx –no-ff
回测

分支创建和切换

分支的创建和切换都是高效的，通过指针完成的

一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

一般合并和快速合并

git pull

一般合并：

本地和远端有新的提交C3、 C4, git pull ,本地和远端分支合并生成C5

快速合并：

本地分支的提交都被包含在了远程分支的提交

Rebase分支合并

rebase是能够将我们对代码的更改从一个分支集成到另一个分支中的git命令之一（另一个命令是Merge）。使用rebase的一个风险在于，它会改写commit历史，如果操作不当那么会是一种破坏性的操作。

风险总是与利益并存的，使用rebase也好处良多，体现在于：

能够保持提交记录的清爽，不带来额外的提交历史（而使用merge会生成一条merge的commit）
能够保持commit线的线性，保持成一条直线，从而能够容易地看出代码是如何推进的

举个例子：

git:(master) git checkout -b feature1

远端master有变更

我们想要同步 master 分支的改动，如果用merge

git:(feature1) git merge master

就会在记录里发现一些 merge 的信息，但是我们觉得这样污染了 commit 记录，想要保持一份干净的 commit，怎么办呢？这时候，git rebase 就派上用场了。

使用rebase同步master变更

在 rebase 的过程中，也许会出现冲突 conflict。在这种情况，git 会停止 rebase 并会让你去解决冲突。在解决完冲突后，用 git add 命令去更新这些内容。

git rebase --continue

这样 git 会继续应用余下的 patch 补丁文件。

在任何时候，我们都可以用 --abort 参数来终止 rebase 的行动，并且分支会回到 rebase 开始前的状态。

git rebase —abort

再回到上文中的工作流图

为什么要定期rebase？

防止最后合并冲突太多

rebase master 后，为啥要git push -f ？

feature1 从C2开始分叉

feature1有新的提交C4, 此时要同步master的最新变更

在feature1 本地 git rebase master，本地产生一个基于C4的新提交C5

这时如果git push会被拒绝，因为feature1远端没有包含C3提交

所以需要git push -f , 并通知项目分支其他成员拉feature1 最新的变动

由于rebase master feature1 提交历史被修改，是一个危险的操作，所以rebase前后都需要通知下该分支下开发的其他成员。

为啥用 git merge feature/xxx –no-ff

--no-ff指的是强行关闭fast-forward方式。

fast-forward方式就是当条件允许的时候，git直接把HEAD指针指向合并分支的头，完成合并。属于“快进方式”，不过这种情况如果删除分支，则会丢失分支信息。因为在这个过程中没有创建commit

git merge --squash 是用来把一些不必要commit进行压缩，比如说，你的feature在开发的时候写的commit很乱，那么我们合并的时候不希望把这些历史commit带过来，于是使用--squash进行合并，此时文件已经同合并后一样了，但不移动HEAD，不提交。需要进行一次额外的commit来“总结”一下，然后完成最终的合并。

转载请注明：汪明鑫的个人博客 » 基于rebase工作流分支策略实践