这是一个系列文章,介绍学习 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!
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。