https://mp.weixin.qq.com/s/gOH8BF_J-eBWxY3NUNlyRw
使用git rebase -i合并提交
https://blog.csdn.net/w57685321/article/details/86597808
使用git pull --rebase避免提交树上出现太多的merge操作
https://blog.csdn.net/qq_15037231/article/details/79723518
https://www.jianshu.com/p/dc367c8dca8e
rebase详解：
https://www.cnblogs.com/chenny7/p/7644318.html
执行git pull --rebase时，若出现了与本地冲突，此时HEAD会指向一个commit id来解决冲突，解决后执行git add，不要执行git commit，执行完git add后，使用命令git rebase --continue来完成rebase。
有个很成熟的叫「Git Flow」的分支模型，它能够应对 99% 的场景，剩下的那 1% 留给几乎不存在的极度变态的场景。
需要注意的是，它只是一个模型，而不是一个工具；你可以用工具去应用这个模型，也可以用最朴实的命令行。所以，重要的是理解概念，不要执着于实行的手段。
简单说来，Git Flow 就是给原本普普通通的分支赋予了不同的「职责」：
master——最为稳定功能最为完整的随时可发布的代码；
hotfix——修复线上代码的 bug；
develop——永远是功能最新最全的分支；
feature——某个功能点正在开发阶段；
release——发布定期要上线的功能。
看到上面的「master」和「develop」加粗了吧？代表它们是「主要分支」，其他的分支是基于它们派生出来的。主要分支每种类型只能有一个，派生分支每个类型可以同时存在多个。各类型分支之间的关系用一张图来体现就是：
