这是一个系列文章,介绍学习 Git 的一个小游戏 - githug,如果你是第一次看到,请先阅读:
闯过这 54 关,点亮你的 Git 技能树
闯过这 54 关,点亮你的 Git 技能树(一)
闯过这 54 关,点亮你的 Git 技能树(二)
闯过这 54 关,点亮你的 Git 技能树(三)
今天我将带大家完成第 31 - 40 关,如对任何命令使用有疑问请看第一篇里的推荐教程。
第三十一关
最近得了一场很严重的病差点儿没挺过来 - 懒癌。让关注此系列的朋友久等了,在这里向你致以最真诚的歉意。
今天我将带大家完成第 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 命令。