merge vs rebase

git规范性

1.整理本地提交历史

本地开发的时候，每开发了一个阶段，我们最好commit一次，但是这就造成了开发一个新功能，会有多个commit的情况，影响提交历史的整洁性 可以使用下面的命令，先查看我们在该功能上一共提交了多少commit，然后将这些合并成一个commit，作为新功能的最终commit

git log # 查看commit次数
git rebase -i HEAD~[num]

2.线性的整洁提交历史

在某个时间点，你打算开发一个新功能，从当时的master（开发进度A）迁出了特性分支，开发一段时间后将dev（开发进度C）推到远端准备提mr，但是此时github显示存在冲突、无法自动合并，这是因为别人基于master（A）开发的新功能早于你合入，所以存在冲突。 这里有两种选择解决冲突

• merge 不建议 squash策略会找到这两个分支的最近共同祖先，然后把两个分支所有的commit全部压缩成一个commit，这两个特性分支上的历史记录都没了
• rebase 建议 保留这些提交历史，并且是线性的。

注意，永远只在你自己的特性分支上rebase，在公共分支通过提mr merge，不要在公共分支rebase！

# 同步更新本地master
git checkout master
git pull origin master

# 开始变基
git rebase master
# 大概率会有冲突，这些冲突是别人新开发的功能，早于你提交
# 解决冲突
git add .
git rebase --continue
# 完成变基

git push
# 如果变基之前已经push过一次，devops上也会显示有conflicts无法automatic merge，所以需要git push -f强制推送、覆盖远程已有的推送

关于rebase和merge，强烈建议阅读https://www.atlassian.com/git/tutorials/merging-vs-rebasing