在入职新公司之后，某一天，共事们在探讨要对某分支进行“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 <commit> --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历史整洁