Welcome everyone

基于rebase工作流分支策略实践

java 汪明鑫 208浏览 0评论

简单介绍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会生成一条mergecommit
  • 能够保持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工作流分支策略实践

喜欢 (5)

说点什么

您将是第一位评论人!

提醒
avatar
wpDiscuz