必备git rebase/cherry-pick

git rebase

要知道git rebase与merge的区别：rebase可以让你的commit聚集在一起。

正常开发来讲，你需要修改bug或是写个功能，会自己创建一个分支。就是从主分支dev-->bug分支

第一天你修改了一个bug，就休息去了
第二天早上，dev已经有很多人提交过代码了，你不能让自己的bug分支还处于落后状态。所以你需要在dev分支git pull
然后再将dev合并到你的bug中。才能让bug分支处于最新的dev基础之上。

怎么合并呢？用git rebase，切换到bug分支后git rebase dev
此时的bug就是最新的状态，你就可以继续开发你的代码。
最后再push到远程端的bug分支上push origin -f bug因为你rebase过，需要强制提交来改变远程端历史状态（如果你第一天已经git push过的话）

那么merge和rebase的区别在哪呢？
如果我第二天用的不是rebase而是merge，区别会在哪：第一天我修改了一个bug就休息，提交了一次commit，记作commit1
第二天我merge以后又提交了一次commit2，那么因为我merge过了，我的两次提交之间会有一大堆其他人的commit记录。
例如：commit1-->commitA-->commitB-->...-->commit2

而如果我使用的是rebase，其他人的记录都会在我的记录之下。
例如:commitA-->commitB-->...-->commit1-->commit2
他会将我们自己的记录聚集起来，能更好地进行观察。虽然时间上是乱的。

还有一点切记。每天早上呢，你需要先
git pull -r
再切换至自己的分支后
git rebase dev
以确保自己的分支仍是处于最新状态的，再开始开发

当你push至远端，bug修改好以后，再在远程端上创建一个pr，让管理员审核你的分支是否可以合并至主线程中。
注：一个分支的pr创建一次即可，即便你修改过分支的东西，push上去就好了。不需要再改pr

---

cherry-pick

想象一个场景，当你做了好几个功能以后，你只想要最后一个功能，就可以用cherry-pick直接将最后一个commit与master合并，后面加最后一个的id即可
git cherry-pick /id/

---