git rebase 和 git merge，实际工作使用

概述

git rebase是用来处理git merge命令所处理的同样的问题。
这两个命令都用于把一个分支的变更整合进另一个分支——只不过他们达成同样目的的方式不同。

场景，你在feature分支上开，另一位团队成员更新了main分支。这将会造成一个分叉的提交历史，对于任何一个使用Git作为代码协作工具的人来说都不会陌生。

现在main分支内新增的内容与你正在开发的新功能有关。为
了把main分支里新增的代码应用在你的feature分支，你有两种方法：merge 和 rebase。

1、使用Merge
最简单的方法就是把main分支合并进功能分支：

git checkout feature
git merge main

这会在feature分支中创建一个合并提交，这次提交会连结两个分支的提交历史，在分支图示结构中看起来像下面这样：

合并操作很友好，因为它没有破坏性。现存的分支历史不会发生什么改变。

2、 rebase
为了替代merge操作，你也可以把feature分支的提交历史rebase到main分支的提交历史顶端：

git checkout feature
git rebase -i main

以上Merge与base的图文解释，是参考改文章：https://blog.csdn.net/kevinxxw/article/details/123980372
我也是看了他的文章，大彻大悟的；

实际工作中的使用

连个分支v1, v2.
现在需要把V2分支合并到v1分支上：
1、 merge方法：

1. V1， V2 上都是最新代码，且没有未提交代码；
2. 切换到v1分支： git checkout v1
3. git merge 2
4. git push -f

2、 Rebase 方法

4. V1， V2 上都是最新代码，且没有未提交代码；
5. 切换到v1分支： git checkout v1
6. git rebase -i v2
7. git push -f

生成分支树，一条线；

如果项目发布：需要把master主分支合并到V1上；继续进行rebase操作

git checkout master
git pull
git checkout v1
git rebase -i master
git push -f

以上是基于项目，做的merge与rebase的对比。

以前工作上，合并代码都是有专门的人员去负责的。现在工作需要自己来负责整个流程，git rebase 与merge一直都没太搞明白，今天终于花一些时间，来攻破这点。技术就是这样，一直学不完，遇到问题解决问题；
后续项目中如遇到相关合并问题，会继续记录；

遇到问题1：

需要把分支 feature1 合并到分支 feature2 上，结果合并反了，把2的分支合并到1的分支上了；
错误操作：

git checkout feature2
git pull
git checkout feature1
git rebase -i feature2
git push -f

解决方案：
把feature1 merge到feature2即可；

git chekout feature2
git merge feature1