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