持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第31天，点击查看活动详情
向着大满贯冲刺! 今天这一篇插入个额外的话题，关于多次提交的合并。
我们在工作中参与团队开发项目，经常会遇到这种东西，比如一个小小的修改被反复提交了多次，到了合入到仓库的时候就会有很多个记录，显得自己很low。
这一篇教大家如何解决这种问题。
(一) 未push的提交合并
先创造这个演示条件。
git commit一些东西几次，也不用搞什么正式的材料，这里就修改了一个文件多次，并多次提交。
操作的记录如下
实现合并操作的命令是git rebase
首先使用** git rebase -i hash值 **进入交互模式
hash值就是我们每次提交的记录编号，通过git log可以查看，pycharm里面也可以通过git 的记录查看，如上图所示。
找到自己要合并的几个commit记录并找到他们的上一次提交。
记录下这个值
执行交互命令前需要保证全部都提交。命令行执行交互命令后显示的如下
hash值是这几次rebase测试的上一次提交的值，这显示的就出来全部的rebase测试的pick
最上面的是最前面提交的一次。顺序和日志中查看是反过来的。
此时合并需要保留第一个pick，并把其他的记录pick改为s
在pycharm中按i进入编辑，按ctrl+c退出编辑并输入:wq保存退出。退出后进入commit消息编辑
在这里#并不生效，所以保留一个commit消息即可
同样保存退出，即可看到rebase消息。
此时就合并为一个了
(二) 已经push上去的rebase合并
其实更多的场景是要和仓库里面已经push过去的记录合并。
还是先构造数据，创建几次提交并推送上去
此时远程仓库的指针和我们当前位置重合
依旧以原来的那次提交为基线。
同样修改这些pick
根据提示的英文，我们能知道s的意思就是将这个记录合并到过去的记录里，所以这里第一个要用pick保留。 对于其他缩写，我们也可以查看下，对于删除、换提交人邮箱等都可以在这里实现。 在提交这次合并前github上记录是这样的
push后会提示你要合入
合入后日志线会有这样的走势变化
这几次的提交记录并不会被删除，而是被合并请求合入了，反而还多了个记录。这肯定不是我们需要的效果。
我们重新做一次记录并合并
在此时用命令的方式强制提交
git push -f
此时的记录才是想要的。但这个一定要注意不要影响其他人在这个期间的操作。
强制提交后的记录河流图变为了这样。
合并中很可能会有冲突，根据提示将冲突的文件修改后重新git add即可
