大家好,我是狼王,一个爱打球的程序员
这篇主要让我们来学习一下Git,这个分布式版本控制系统
在日常工作中,经常会用到Git操作。但是对于很多人来讲,刚上来对Git很陌生,操作起来也很懵逼。本篇文章主要针对刚开始接触Git的新人,理解Git的基本原理,掌握常用的一些命令。
什么是版本控制?我真的需要吗?版本控制是一种记录若干文件内容变化,以便将来查阅特定版本修订情况的系统。
分布式版本控制系统( Distributed Version Control System,简称 DVCS )。
在这类系统中,像 Git,Mercurial,Bazaar 以及 Darcs 等,客户端并不只提取最新版本的文件快照,而是把原始的代码仓库完整地镜像下来。这么一来,任何一处协同工作用的服务器发生故障,事后都可以用任何一个镜 像出来的本地仓库恢复。因为每一次的提取操作,实际上都是一次对代码仓库的完整备份。
更进一步,许多这类系统都可以指定和若干不同的远端代码仓库进行交互。借此,你就可以在同一个项目中,分别和不同工作小组的人相互协作。你可以根据需要设定不同的协作流程,比如层次模型式的工作流,而这在以前的集中式系统中是无法实现的。
以上包括一些简单而常用的命令,但是先不关心这些,先来了解下面这4个专有名词。
指的是在PC中能看得到的创建的一个管理仓库的目录,比如我的test文件夹就是一个工作区:如下图:
.git目录下的index文件, 暂存区会记录git add添加文件的相关信息(文件名、大小、timestamp...),不保存文件实体, 通过id指向每个文件实体。可以使用git status查看暂存区的状态。暂存区标记了你当前工作区中,哪些内容是被git管理的。
当你完成某个需求或功能后需要提交到远程仓库,那么第一步就是通过git add先提交到暂存区,被git管理。
保存了对象被提交 过的各个版本,比起工作区和暂存区的内容,它要更旧一些。
git commit后同步index的目录树到本地仓库,方便从下一步通过git push同步本地仓库与远程仓库的同步。
远程仓库的内容可能被分布在多个地点的处于协作关系的本地仓库修改,因此它可能与本地仓库同步,也可能不同步,但是它的内容是最旧的。
下面这幅图更加直接阐述了四个区域之间的关系,可能有些命令不太清楚,没关系,下部分会详细介绍。
网上找了个图,别人整理的一张图,很全很好,借来用下。下面详细解释一些常用命令。
在掌握具体命令前,先理解下HEAD。
这要从git的分支说起,git 中的分支,其实本质上仅仅是个指向 commit 对象的可变指针。git 是如何知道你当前在哪个分支上工作的呢?其实答案也很简单,它保存着一个名为 HEAD 的特别指针。在 git 中,它是一个指向你正在工作中的本地分支的指针,可以将 HEAD 想象为当前分支的别名。
add相关命令很简单,主要实现将工作区修改的内容提交到暂存区,交由git管理。
git add -A 和 git add . 和 git add -u 的区别
git add -A : 把所有变化提交到索引库,包含当前git仓库的所有目录
git add -u : 提交被修改(modified)和被删除(deleted)文件,不包括新文件(new)
git add . : 该操作与git 的版本有关:
-1.x 版本:提交新文件(new)和被修改(modified)文件,不包括被删除(deleted)文件
-2.x 版本:和git add -A一样,提交所有变化
git commit 主要是将暂存区里的改动给提交到本地的版本库。每次使用git commit 命令我们都会在本地版本库生成一个40位的哈希值,这个哈希值也叫commit-id,commit-id在版本回退的时候是非常有用的,它相当于一个快照,可以在未来的任何时候通过与git reset的组合命令回到这里.
涉及到协作,自然会涉及到分支,关于分支,大概有展示分支,切换分支,创建分支,删除分支这四种操作。
关于分支的操作虽然比较多,但都比较简单好记。
Git的git-merge是在Git中频繁使用的一个命令,很多人都觉得git合并是一个非常麻烦的事情,一不小心就会遇到丢失代码的问题,从而对git望而却步。
merge命令把不同的分支合并起来。如上图,在实际开放中,我们可能从master分支中切出一个分支,然后进行开发完成需求,中间经过R3,R4,R5的commit记录,最后开发完成需要合入master中,这便用到了merge。
rebase又称为衍合,是合并的另外一种选择。
在开始阶段,我们处于new分支上,执行git rebase dev,那么new分支上新的commit都在master分支上重演一遍,最后checkout切换回到new分支。这一点与merge是一样的,合并前后所处的分支并没有改变。git rebase dev,通俗的解释就是new分支想站在dev的肩膀上继续下去。rebase也需要手动解决冲突。
rebase与merge的区别
现在我们有这样的两个分支,test和master,提交如下:
D---E test
/
A---B---C---F master
在master执行git merge test,然后会得到如下结果:
D--------E
/ \
A---B---C---F----G test, master
在master执行git rebase test,然后得到如下结果:
A---B---D---E---C'---F' test, master
可以看到,merge操作会生成一个新的节点,之前的提交分开显示。而rebase操作不会生成新的节点,是将两个分支融合成一个线性的提交。
如果你想要一个干净的,没有merge commit的线性历史树,那么你应该选择git rebase 如果你想保留完整的历史记录,并且想要避免重写commit history的风险,你应该选择使用git merge
有时候,我们用Git的时候有可能commit提交代码后,发现这一次commit的内容是有错误的,那么有两种处理方法:
第一种方法比较直接,但会多次一次commit记录。而我个人更倾向第二种方法,错误的commit没必要保留下来。
reset命令把当前分支指向另一个位置,并且相应的变动工作区和暂存区。
git revert用一个新提交来消除一个历史提交所做的任何修改。
revert与reset的区别
git push的一般形式为 git push <远程主机名> <本地分支名> <远程分支名> ,例如 git push origin master:refs/for/master ,即是将本地的master分支推送到远程主机origin上的对应master分支, origin 是远程主机名
以上就是关于Git的一些常用命令及详细阐述,相信能对Git有一个初步的认识。