这同样是一个非常有用的技巧
我讲解的这些命令，其实都是git官方推荐的核心和重要的命令以及操作
就是说，我的高阶的实战部分，涵盖的这些命令，本来就是大家都需要掌握的，而且都是很重要的
但是我讲课的风格，就是实战驱动，业务驱动，项目驱动
所以我必须是以我在好多个大公司里面工作过，经历过的各种真实的场景，给大家来铺垫每个git命令的背景，这样的话，大家第一，听的时候不会很枯燥，git rebase，git bisect，背景铺垫，实战场景铺垫；大家结合我说的这些真实的工作场景中，如何运用这些git命令，也可以让大家更好的去理解，你学习的这些东西，可能在未来什么时候会派上用场
比如我们现在在一个业务团队里面工作，开发了一个工作流中间件系统，支撑了团队里多个项目的发展，挺好，对吧
然后呢，嗯。。。BAT里某一家最常说的，拥抱变化，拥抱变化
这个业务团队副总裁觉得干的不咋地，于是决定玩儿一把权术厚黑，把团队里部分项目拆分出去，提拔原来团队里的一个经理变成了总监，带另外一个独立团队，此时会有什么效果，被拆出去的那个新任总监，肯定是会觉得，哇塞，天上掉馅饼，我一下子就成总监了
肯定是吭哧吭哧吭哧，拼命干，每天干到凌晨3点，每天看着凌晨3点的北京的风景，甚至是偶尔看看凌晨6点北京日出，他也会干
此时就要。。。4个业务系统可以拆分出去，2个业务系统
但是，4个业务系统都是由一个支撑性的工作流中间件去支撑的，这个时候怎么办呢？基础支撑性系统呢？？？
尴尬了。。。但是团队A的基础系统支撑团队B的业务系统？？？
当然不行了，拆！！！
基础支撑系统直接拷贝一份代码，上传到另外一个git仓库，给那个团队去维护
此时团队A就要负责项目代码的迁移，那么就有一个注意的点，一般这个时候，其实都是要抹掉之前所有的提交历史的，让新团队接手的那份代码，commit提交历史就一个初始提交记录
这个是为什么？因为新团队里会招聘新的人过来，此时如果新的人看以前的commit提交历史，都是别的团队的人的，其实不太好的，跨团队之前，尽量不要有这么多的耦合，否则会弄的大家很迷糊
一般大公司里面，跨团队，项目代码也是比较敏感的，即使可以拷贝代码，但是说之前的一些提交历史最好还是要抹掉的，看起来这就像一个全新的项目一样
将原来的一个仓库拆分成两个仓库
echo 'get history from blah blah blah' | git commit-tree 9c68fdc^{tree}
我们从要截断的那个commit的上一个commit，创建一个基准commit出来，比如用倒数第二个commit
git rebase --onto 622e88 9c68fdc
接着，执行git rebase --onto命令，将倒数第二个commit之后的commit重新基于那个commit基础之上来构建提交历史
此时，master分支代码就会只保留了2个commit
然后可以将这个master分支的代码和commit历史提交到另外一个新的代码仓库上去，那个代码仓库就会仅仅保留两个commit了
我是特意没有将详细的步骤记录下来的
因为我是希望大家能够自己一边看视频，一边记录下来git的操作记录，然后自己动手去实验，去体会里面的所有的操作
因为git这块本身不涉及到什么代码，所以还是希望大家自己多动手
但是后面的内容，正式进去项目开发以后，为了保证每个同学学习的进度和质量，都是会给出非常完整的课程之后自己写代码的实验手册