这是一个系列文章，介绍学习 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！