我的GIT知识盲区

在入职新公司之后，某一天，同事们在讨论要对某分支进行“cherry-pick”，而我却一头雾水。这时候我知道，是时候该对git知识扫扫盲了！

（本着不重复造轮子的原则，相当多的知识点没有在本文展开，而是以link的方式给出）

远程仓库的默认名字是origin！

很典型而且很可能显得很白痴的问题，但是在很长的一段时间内，在不知道origin是什么的情况下，git pull 和 git push 以及一些自动的命令补全，魔法般的将我的代码推向了远程仓库！

例子：
某次我clone错了repo，本来应该clone repoA，但是却clone了repoA的某一个fork（fork的repo和repoA同步）。如果在以前，我可能会删除掉当前的本地clone，然后再次clone一份；而在知道origin代表远程地址的情况下，我简单的通过修改.git/config中origin指向的地址，解决了该问题。

任何操作都可以都可以恢复！git reflog

我不了解git reflog的命令前，常常会懊恼的删除掉本地仓库，然后在clone一份新的repo，通过这种方式来解决一些merge失误等问题，因为我一度以为有些操作会对codebase产生不可逆的结果！

但是git已经替你考虑到这种情况，这个命令会把你的每一个指令和commit号显示出来，也就是说，即使某一个commit在branch和log中找不到了，你仍然可以通过reflog在操作日志中找到它！然后通过git reset --hard的方式进行恢复！

参考文章

Detached Head， 什么是Head？为什么Detach？

Head有点像一个特殊的指针，Git的作业，永远发生在Head指向的地方上，比如：如果Head指向的是某一个branch，那么codebase实际显示就是某一个branch的code。当我们切换分支的时候，实际就是将Head指向不通的branch。

所以 一般来说Head是指向branch的，当我们想操作某一个特定的commitID的代码时，那么我们就需要吧Head和branch解除绑定，分离开！这也就是Detached Head的由来。

git stash 先看主线bug，回头继续开发！

之前编程中遇最烦心的事，莫过于当前的代码开发了一半，突然需要查看一个主线版本的bug，这时候我既不想丢弃目前的开发进度，但是也不想把还没有完成的代码commit上去，在使用stash之前，我可能会傻傻的将repo在本地复制一份！

但是通过git stash, 我们可以现将改动暂存起来，回到主线分支（或其他分支），等问题结局之后，在把改动放回来继续工作！

不过stash其实功能比上述介绍更加的丰富一些！大家可以参考此处。

fetch + merge is better than pull

使用git pull命令，git魔法般帮我们完成了大部分的工作，但是如果想知道“魔法”的原理，而不是像一个麻瓜一样，那我建议从现在开始，开始使用（或者至少使用几次） git fetch + git merge的方法从远程仓库下拉改动。

参考：fetch and merge, don't pull

cherry-pick 很炫的名字，很基础的操作

虽然cherry-pick的名字很炫，但是其实对应的一个非常基础的功能，即将某一个branch的某一个commit，移动到另个branch上。

人的一生，总有几次需要采摘的时刻呀。

参考：一个可以提高开发效率的命令：cherry-pick

rebase 协作的基石

只要在团队中协作，那么必然会遇到主线代码比当前本地代码更新的情况，而掌握rebase也是协作中绕不开的知识点！

参考：合并分支
在这篇文章中，对比了merge和rebase两种合并代码的方式，以及一个经常会听到的概念fast-forward，最棒的是图例清晰，非常值得一读。

squash 要优雅，要绅士

squash 是基于 git rebase的操作，可以将多个commit合并为一个commit，简单清晰的commit提交记录，难道不是一个绅士coder基本的要求吗～？

如何保持Git历史整洁