git中，分支合并常用的两种方法rebase和merge。
git merge
将分支进行合并
在feature1上面git merge develop 。即为拉取develop的改动到feat。
feature1 分支上产生一个新的 commit, 这个commit就是包含了 develop 分支的修改。
git rebase
本意为：Reapply commits on top of another base tip 在另一个基础上进行commit应用。rebase存在多种使用情况。最常用的就是分支合并。
拉取develop分支的改动更新到feature1分支。（若改动涉及同一位置，则解决冲突）
- 命令行操作： (在feature1目录下)
git rebase develop。即为拉取develop的改动到feat。 - webstorm操作：处在feat分支下，点击develop，点击 Rebase Current onto Selected,
显示"rebase feat onto develop"。表示为拉取develop的改动到feat。
git rebase原理说明：
git rebase 被称为变基，变基为何意？
就是把当前分支的commit进行截取，接在其他分支最新的commit后面。由此，这种解释更加贴切，而且更容易理解，便于和merge区别开来。
- git 会把 feature1 分支里面的每个 commit 取消掉；
- 其次，把上面的操作临时保存成 patch 文件，存在 .git/rebase 目录下；
- 然后，把 feature1 分支更新到最新的 master 分支，原feature1 分支的commit结构将会被丢失
- 最后，把feature1 分支保存的 patch 文件应用到 master分支上； 如图所示：
不同的使用场景：
-
如果你在开发阶段，尤其是多人协作的时候，需要清晰的知道代码的来龙去脉，使用 merge
-
多个人开发同一个模块。很可能他的某个改动会导致你的功能出问题，如果出了问题，保留记录能便于后期排查问题，使用 merge
-
如果你写了一个代码库发布出去给别人用，你需要保持一个干净版本历史，这时你的分支合并信息就是冗余的了，推荐使用 rebase
-
同事修改的模块与自己的模块没有关联，拉取别人修改的模块，或者说在自己个人的分支上开发，合并代码也不会影响功能。推荐使用 rebase
使用Rebase要注意
- 注意操作的是rebase一直是自己的分支，将merge的改动拉取到自己的分支来，改动自己分支的commit。而不是将master进行了rebase操作，改动master
- 如果rebase后的分支要推到远端，会由于分支改动，跟远端commit历史信息产生冲突，而无法推成功。这时候就要用强推git push -f
解答最后的疑惑：第三种merge
（1）为何先在feat分支上变基rebase主分支呢？再将feat合并marge到主分支呢？
feat和develop分支的区别在： 1、 feat的改动代码 2、develop的迭代代码
我们从始至终的操作都是：在feat上面git rebase develop /master。 即为拉取这些分支的改动到我们自己的feat。也就是理解为：把代码合并在了feat分支上。
此时feat和develop分支的区别在：1、feat的改动代码。
我们再将feat合并入master时候，进行分支比较时，可以清晰看到feat的改动代码。
（2） master 是怎样合并其他分支代码的呢？
一个项目进行严格的仓库管理，重要分支会设有分支改动的测试和审核人员。
这个情况，远程仓库的这个分支是不允许除管理员意外的人去操作变更分支代码的。想merge重要的分支采用的是 merge requestd的方式。将会对代码进行人员指配，来完成对代码的测试审核。
保姆级教程，并配有每一步操作的图片示例：zhuanlan.zhihu.com/p/431865877
git rebase 的其他常见用法
用于修改commit，对多个commit进行合并
-
git rebase -i HEAD~4 合并近四个commit
-
合并分支的commit，选择commit状态。
-
git rebase --continue
