这是一个系列文章，介绍学习 Git 的一个小游戏 - githug，如果你是第一次看到，请先阅读：
闯过这 54 关，点亮你的 Git 技能树
闯过这 54 关，点亮你的 Git 技能树（一）
闯过这 54 关，点亮你的 Git 技能树（二）
闯过这 54 关，点亮你的 Git 技能树（三）
今天我将带大家完成第 31 - 40 关，如对任何命令使用有疑问请看第一篇里的推荐教程。
第三十一关
当准备做的事情有可能会破坏其它东西时，为了不影响其他同事的开发工作，我们通常会拉一个分支出来，在分支上去做修改。
第三十二关
上一条命令只是创建了一个新的分支，并没有 checkout 过去，习惯做法通常是直接 git checkout -b xxx，创建并 checkout 到新的分支。
如果使用 oh-my-zsh 的 git 插件的话，可以用 gbc，意思是：git branch create。
第三十三关
版本 1.2 存在 bug，这里我们需要切换到 1.2 的代码以定位问题。Checkout tag 和分支没有什么区别。
第三十四关
但当存在同名的 tag 和分支时，git 不知道我们究竟是要 checkout 到 tag 还是到分支，它认为分支的优先级更高。
这时就要显式地告诉 git 我们是要切换到 tag。
第三十五关
有时忘记开新的分支，就修改并提交了代码。开分支的时候默认是基于最新的一次提交的，但我们也可以指定参数使其基于任一次提交。
第三十六关
分支开太多就不好管理，不管使用哪种分支模型，只有很少的分支会长期存在，大部分分支都是临时的，在代码合并后就会删除掉。
第三十七关
有时候在特性分支上提交了代码，但还不能并入主干，却又希望和别的同事分享（比如需要他们帮做 Code Review），那就需要把分支 push 到远程仓库中去。
第三十八关
将另一个分支并入当前工作分支。
第三十九关
当远程仓库有更新，但我们并不想合并到本地仓库，只想把代码拿下来看看，我们会用到 fetch 命令。
第四十关
Rebase 这里如果不理解，请看第一篇里的推荐教程。
今天就到这里了，明天（下次）再见！
如果想第一时间得到更新，请关注 CodingStyle.cn！
