我的GIT知识盲区

我的GIT知识盲区_第1张图片

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

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

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

很典型而且很可能显得很白痴的问题,但是在很长的一段时间内,在不知道origin是什么的情况下,git pullgit 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历史整洁

你可能感兴趣的