git merge 和 git rebase 的使用场景

git merge 和 git merge是不同的

1、常规的git merge， 快速合并

我们在dev上开发，完成feature之后，确认代码无误，然后可以提交远端或合并到主分支。
当把dev合并到main的时候，需要切换到main分支，然后执行命令.

$ get checkout master
$ git merge dev

这样做一般没什么问题，但是，这中合并是直接把HEAD指针合并分支的头，完成合并。属于快进方式，如果我们删除dev分支，就会丢失分支信息。因为在这个过程中没哟创建commit
这样的合并就是 $ git merge ff, 就是快速合并。

2、关闭快速合并

$ git merge --no-ff
他可以在合并时保留分支的commit 历史

3、git merge --squash

此种合并方式会把 分支中的多次commit 提交历史压缩为一次，减少开发中多次繁杂的提交历史记录。

4、git rebase

git rebase 的适用场景，
有这样的场景：
假如我和同事小王分别从主分支 main 拉取了自己的开发分支 dev_Jarvis, dev_wang,
现在主分支有提交记录 1，2，3
此时dev_Jarvis, dev_wang, 分支的初始状态都是 1，2，3
现在小王开发了 4，5，6， 我开发了 6，7，8
如果此时小王开发完成，提交了记录到 远端remotes/origin/dev_wang。
之后我也开发完成，由于我需要4，5，6的功能。
此时，我用命令，git rebase origin/dev_wang，就可以在我的分之上添加小王先提交的代码, 换基操作使得我合并到了小王的代码，并且我的分支没有和小王的分支交叉。
同理，我和小王的互换操作，小王的分支和我的也没有交叉，这样的代码历史路线就很清晰。

当然，只要代码没有致命BUG，提交的代码之间没有依赖也可以这样做。

这样，我和小王就可以继续开发，小王开发 9，10，11， 我开发，12，13，14
从此循环往复。
最后，这个版本开发完成，正常上线，就可以把 dev_Jarvis, dev_wang, 全部提交远端，合并到main分支。

如果用普通的merge 也可以完成，我们要怎么做呢？

• 小王本地开发完成 4，5，6 提交push到 远端分支，origin/dev_wang
• 我本地pull他的分支，本地会有 /dev_wang
• 然后我 吧dev_wang 合并merge到我的 dev_jarvis
• 最后我再推送push我的代码到 origin/dev_jarvis
• 小王拉去我的分支，这样，俩的开发分支就同步了，发现比rebase麻烦了不少。

试想，如果是多人协同开发，团队有几十上百人，我们不停的拉取，合并，推送，每个人提交到远端的的代码我们都需要来一遍，真的是麻烦,而且log 里的提交日志会是相互交叉，让人看着头大。

当然，如果是小团队，一般一个版本对应一个dev分支，多人都可以提交到此dev分支。只要push前 pull, 遵循规则，遇到冲突随时解决，也不会很麻烦。
最后发版稳定之后就可以合并到主分支了。