前段时间提了几个pr给开源社区，此篇记录下git一个很基本的功能——rebase使用。
讲一下前因后果吧，虽然我经常使用git但是基本都是我自己提交给自己的仓库，也就没养成一个功能一个commit或一个bug一个commit这种习惯，基本上写了一点点就提交上去。但是多人功能维护一个仓库的话这些必须得严格遵守的，别人审查代码也比较方便。
commit合并
现学现卖，人家非要我用一个commit把代码提交上去，只能花费点时间学学怎么搞了。可能会有部分说明不是特别准确，评论私信我有时间更新修改。
原理
例如有两个人A和B同时维护一个仓库，A在12点的时候fork了master分支来开发自己新加的功能，等到A在18点开发完后想把自己的分支合并到master分支上时却发现B在14点的时候提交了代码到master分支上。
通常这种情况下大家应该选择的都是merge吧，等merge完后你就会发现git提交记录里面就会很乱。更甚说你俩开发的其实可以说是一个功能，为了使master分支上提交记录利读，这就需要把你俩提交的所有commit合并成同一个commit。
你俩是从不同的节点拉的代码，合并是不可能合并在一起的，这就只能用rebase来变基。
演示
为了方便查看，这里就直接用idea来演示了。主要是解决冲突的时候git本身提供的面板实在难用，不像idea可以全部接受自己本地更改的代码。
如果像是这样一条直线的话那就不需要rebase了，可以直接选择你想要合并的commit然后Squash Commits把这几个合并成一个Commit。
重新写个Commit信息后即可合并成功了。
但如果前面有从别端merge进来的话，我们想把这个也合并到一起的话就会报错。
这时就需要rebase登场了，需要改变其基点把commit都移动到主分支上。在你想要rebase的commit上右键然后选择Interactively rebase from here。
过程中可能会有冲突，需要你手动解决。
等待rebase成功即可，可以看到都是一条直线了，如果想合并成一条commit的话可以按照上面squash一下再推送到远端。
适用场景
- 多人共同开发，比如提交开源代码。为了提交记录简洁肯定需要把某个功能实现或bug修改所有提交的commit合并成一个。
- 强迫症患者，自己私人仓库也可以按照一个功能一个commit来要求自己。
闲聊
今天重构了下宝藏指南站点的代码，以后请叫我java-go，写的go项目也完全按照了java的分层结构(¬､¬)。今天按照gin-vue-admin项目重构了下好吧，感觉看得顺眼多了。主要是java有bean自动管理，根本不需要考虑实例什么时候初始化，导致我写go的时候就随便乱放了，等到代码多了起来的时候就贼难找到了，可读性很差。
为了防止以后变成屎山，只能重构了，幸亏改完了还能运行(๑•̀ㅂ•́)و✧
今天请假一天，感觉生活又充满希望了好吧。本来今天也想写下爬公众号所有文章的，遇到了点问题等周末吧。
相关文章
