git merge 合并的几种方式 squash 和 rebase 区别
总结：
- rebase 可以尽可能保持 master 分支干净整洁，并且易于识别 author
- squash 也可以保持 master 分支干净，但是 master 中 author 都是 maintainer，而不是原 owner
- merge 不能保持 master 分支干净，但是保持了所有的 commit history，大多数情况下都是不好的，个别情况挺好
squash 使用：squash merge
在使用 git 的过程中，可能你遇到过想要合并多个 commit 为一个，然后很多人会告诉你用 git commit --amend，然后你发现里面有你的多个 commit 历史，你可以通过 pick 选择，squash 合并等等。同样得，merge 的时候也可以这么干，你只需要这么简单的两步：
- 切换到目标分支：git checkout master
- 以 squash 的形式 merge：git merge --squash devel
你会发现，在 master 分支上居然有未提交的修改，然后你就需要在 master 上主动提交了修改，注意，这里是你 commit 的，也就是改变了 commit 的 author。
rebase 使用
但是，作为处女座的程序员肯定是不能忍受目前的情况的，因为我们既想合并 commits，又想保留作者的信息，那么有没有什么好办法呢？肯定是有的啦，这个时候我们可以尝试一下 rebase，操作步骤是这样的：
- 先切换到 devel 分支（不一样咯）：git checkout devel
- 变基：git rebase -i master
- 切换回目标分支：git checkout master
- 合并: git merge devel
这里完成了第二步之后我想你应该大概知道发生了什么事了，我们在 devel 里面对照 master 进行了变基，所谓的变基其实就是找到两个分支共同的祖先，然后在当前分支上合并从共同祖先到现在的所有 commit，所以我们在第二步的时候会选择怎么处理这些 commit，然后我们就得到了一个从公共commit 到现在的单个 commit，这个时候别人讲我们这个 commit 合并到 master 也只会在 master 上留下一个 commit 记录，就像这样：
虽然这个 commit history 线看上去很不错，而且也比较符合实际情况，但是我们需要注意到的有点就是分支上的开发者需要自己执行变基操作，从而导致他的原始 commit history 变化了（可以理解成被合并了）。
原文：
https://www.jianshu.com/p/684a8ae9dcf1
版权属于：Joyber
本文链接：https://blog.qqvbc.com/default/363.html
转载时须注明出处及本声明