本次代码剥离给了我一个深刻的教训。
背景：
上个月我们团队有一个和其它团队合作的项目，前端要配合其它团队一起发布上线。我们日常的发布流程是每周三一次，这个时候的改动会上release分支，而日常的改动会到master分支上。
开发过程：
和master代码同步之后，我就开始开开心心地写代码了，每次写好一部分代码，我再去master上看看，又有好多代码没同步，就又同步了一把。
这样同步了若干次，开发了持续半个月，第三周周四，忽然收到隔壁团队的通知，我们组要配合他们周五发布上线，也就是我要把master的代码提取出来到release分支上去。
这就造成了提交的代码和同步的代码混在一起，又多又乱，而我只能把我的代码提取出来，不能提取别人的代码出来。
本来我自信是要提交到master的，我没有一点可能要改分支的觉悟，提到master并且做了一次又一次的代码同步，把自己的分支管理的一塌糊涂。
我在gitlab上切换了提交的分支，把master改成了release，可是却看到把别人的（我同步的）代码也merge进来了。
解决问题：
遇到问题，我通常第一念头是找若干种解决方案，再选一个最好的。
这种情况，我第一念头是把若干个提交一个一个的cherry-pcik出来，可是这样，就会异常缓慢。
忽然想到git rebase 的命令可以把一次次的代码提交合并起来，再cherry-pick出来。
git rebase -i commitId 可以把该commitId之后的提交都merge到一个commit上。这样我只需要合并两个master同步之间的代码，再cheery-pick这一次就好了。
git rebase -i commitId就可以把从不包括该commitId到之后的提交都合并到该commitId上去。
（简便操作$ git rebase -i HEAD~2 可以把从当前往前数的前两个分支合并了）。
参考：
https://blog.csdn.net/tq384998430/article/details/77745600
https://blog.csdn.net/kongxingxing/article/details/48679669
