git-在当前分支做变基(rebase current onto selected)

news2024/9/20 8:07:55

文章目录

- git rebase变基
- git rebase使用场景
- git rebase还是git merge?
- 在当前分支做变基
- 使用总结

git rebase变基

初学git，在合并分支上必定会常用到 git merge 语法。git除了使用合并(merge)集成2个分支之间的更改，还有另外一种称为rebase的方法。

git rebase <基础分支>

rebase的作用是改变基点。rebase把当前分支的基点，由与基础分支的共同祖先处，移动到基础分支的头部位置处，然后以新基点为基础，重新提交当前分支中的更改。

git rebase使用场景

Git中分支merge和rebase的适用场景及区别
参考URL: https://www.cnblogs.com/marblemm/p/7161614.html
git merge rebase的区别及应用场景
参考URL: http://www.mamicode.com/info-detail-1774810.html

两个使用场景是不一样的，merge只是合并另外一个分支的内容，rebase也合并另外一个分支的内容，但是会把本分支的commits顶到最顶端

假设我们现在有3个分支

master分支：线上环境使用的分支
testing分支：测试环境使用的分支
my_feature分支：开发新功能的分支，也就是当前分支

A. 假设我在my_feature上开发了一段时间，之后另外的同事开发的功能正式上线到master分支了，那么我可以在当前的分支下rebase一下master分支，这样我这个分支的几个commits相对于master还是处于最顶端的，也就是说rebase主要用来跟上游同步，同时把自己的修改顶到最上面

B. 我在my_feature上开发了一段时间了，想要放到testing分支上，那就切到testing，然后merge my_feature进来，因为是个测试分支，commits的顺序无所谓，也就没必要用rebase (当然你也可以用rebase)

另外，单独使用rebase，还有调整当前分支上commits的功能(合并，丢弃，修改commites msg)

git rebase还是git merge?

在开发过程中使用git rebase还是git merge，优缺点分别是什么？
参考URL: https://www.zhihu.com/question/36509119

两个使用场景是不一样的，merge只是合并另外一个分支的内容，rebase也合并另外一个分支的内容，但是会把本分支的commits顶到最顶端

merge 的话，会产生一个commit，记录合并的操作，可能是没有冲突自动生成的merge commit，也可能解决冲突后自己编写的 commit。总之多了一个 commit。

支持merge多一点，原因如下：

rebase过程中，一个commit出现冲突，下一个commit也极有可能出现冲突，一次rebase可能要解决多次冲突；
合并的历史脉络（冲突）被物理消灭了
merge，合并结果不好看，一堆线交错，但合并有冲突的话，只要解一次就行了；

来自网上：有人说：“团队里有新人且水平参差不齐的情况下，建议统一 git merge，不然容易出来麻花，过去解完麻花再传授一番 git rebase 的原理，然后 git push -f 一发又有什么收益呢”。

为了追求Git的线好看，在团队合作中使用rebase说轻点是舍本逐末，说重了是对团队不负责任。个人以及本地项目无所谓。

总结：支持merge多一点，团队合作建议用merge。一般私有的用rebase，公开的用merge。（如果团队成员对于git的分支管理并不娴熟，那我推荐使用merge。）**开源项目中，我们一般会推荐commitor在提交PR前做一次rebase。**审核通过后，PR的commit list会合并成一个patch打到主分支中。所以无论是不是做过rebase，最终表现在master上都只是一个独立的commit。

在这里插入图片描述