【干货】教你打通Git的任督二脉

发表于 3年以前 | 总阅读数：339 次

在日常工作中，经常会用到Git操作。但是对于很多人来讲，刚上来对Git很陌生，操作起来也很懵逼。本篇文章主要针对刚开始接触Git的新人，理解Git的基本原理，掌握常用的一些命令。

关于版本控制

什么是版本控制？我真的需要吗？版本控制是一种记录若干文件内容变化，以便将来查阅特定版本修订情况的系统。

什么是分布式版本控制系统

分布式版本控制系统（ Distributed Version Control System，简称 DVCS ）。

在这类系统中，像 Git，Mercurial，Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照，而是把原始的代码仓库完整地镜像下来。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的提取操作，实际上都是一次对代码仓库的完整备份。

更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。借此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。你可以根据需要设定不同的协作流程，比如层次模型式的工作流，而这在以前的集中式系统中是无法实现的。

一、Git工作流程

以上包括一些简单而常用的命令，但是先不关心这些，先来了解下面这4个专有名词。

Workspace：工作区
Index / Stage：暂存区
Repository：仓库区（或本地仓库）
Remote：远程仓库

工作区

指的是在PC中能看得到的创建的一个管理仓库的目录，比如我的test文件夹就是一个工作区：如下图：

暂存区

.git目录下的index文件, 暂存区会记录git add添加文件的相关信息(文件名、大小、timestamp...)，不保存文件实体, 通过id指向每个文件实体。可以使用git status查看暂存区的状态。暂存区标记了你当前工作区中，哪些内容是被git管理的。

当你完成某个需求或功能后需要提交到远程仓库，那么第一步就是通过git add先提交到暂存区，被git管理。

本地仓库

保存了对象被提交过的各个版本，比起工作区和暂存区的内容，它要更旧一些。

git commit后同步index的目录树到本地仓库，方便从下一步通过git push同步本地仓库与远程仓库的同步。

远程仓库

远程仓库的内容可能被分布在多个地点的处于协作关系的本地仓库修改，因此它可能与本地仓库同步，也可能不同步，但是它的内容是最旧的。

小结

任何对象都是在工作区中诞生和被修改；
任何修改都是从进入index区才开始被版本控制；
只有把修改提交到本地仓库，该修改才能在仓库中留下痕迹；
与协作者分享本地的修改，可以把它们push到远程仓库来共享。

下面这幅图更加直接阐述了四个区域之间的关系，可能有些命令不太清楚，没关系，下部分会详细介绍。

二、常用Git命令

网上找了个图，别人整理的一张图，很全很好，借来用下。下面详细解释一些常用命令。

HEAD

在掌握具体命令前，先理解下HEAD。

这要从git的分支说起，git 中的分支，其实本质上仅仅是个指向 commit 对象的可变指针。git 是如何知道你当前在哪个分支上工作的呢？其实答案也很简单，它保存着一个名为 HEAD 的特别指针。在 git 中，它是一个指向你正在工作中的本地分支的指针，可以将 HEAD 想象为当前分支的别名。

add

add相关命令很简单，主要实现将工作区修改的内容提交到暂存区，交由git管理。

git add . 添加当前目录的所有文件到暂存区
git add dir 添加指定目录到暂存区，包括子目录
git add file 添加指定文件到暂存区

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一样，提交所有变化

commit

git commit 主要是将暂存区里的改动给提交到本地的版本库。每次使用git commit 命令我们都会在本地版本库生成一个40位的哈希值，这个哈希值也叫commit-id，commit-id在版本回退的时候是非常有用的，它相当于一个快照,可以在未来的任何时候通过与git reset的组合命令回到这里.

git commit -m message 提交暂存区到本地仓库,message代表说明信息
git commit file -m message 提交暂存区的指定文件到本地仓库
git commit --amend -m message 使用一次新的commit，替代上一次提交

branch

涉及到协作，自然会涉及到分支，关于分支，大概有展示分支，切换分支，创建分支，删除分支这四种操作。

git branch 列出所有本地分支
git branch -r 列出所有远程分支
git branch -a 列出所有本地分支和远程分支
git branch branch-name 新建一个分支，但依然停留在当前分支
git checkout -b branch-name 新建一个分支，并切换到该分支
git branch --track branch remote-branch 新建一个分支，与指定的远程分支建立追踪关系
git checkout branch-name 切换到指定分支，并更新工作区
git branch -d branch-name 删除分支
git push origin --delete branch-name 删除远程分支

关于分支的操作虽然比较多，但都比较简单好记。

merge

Git的git-merge是在Git中频繁使用的一个命令，很多人都觉得git合并是一个非常麻烦的事情，一不小心就会遇到丢失代码的问题，从而对git望而却步。

merge命令把不同的分支合并起来。如上图，在实际开放中，我们可能从master分支中切出一个分支，然后进行开发完成需求，中间经过R3,R4,R5的commit记录，最后开发完成需要合入master中，这便用到了merge。

git fetch remote merge之前先拉一下远程仓库最新代码
git merge branch 合并指定分支到当前分支一般在merge之后，会出现conflict，需要针对冲突情况，手动解除冲突。主要是因为两个用户修改了同一文件的同一块区域。

rebase

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

reset

有时候，我们用Git的时候有可能commit提交代码后，发现这一次commit的内容是有错误的，那么有两种处理方法：

修改错误内容，再次commit一次
使用git reset 命令撤销这一次错误的commit

第一种方法比较直接，但会多次一次commit记录。而我个人更倾向第二种方法，错误的commit没必要保留下来。

reset命令把当前分支指向另一个位置，并且相应的变动工作区和暂存区。

git reset —soft commit 只改变提交点，暂存区和工作目录的内容都不改变
git reset —mixed commit 改变提交点，同时改变暂存区的内容
git reset —hard commit 暂存区、工作区的内容都会被修改到与提交点完全一致的状态
git reset --hard HEAD 让工作区回到上次提交时的状态

revert

git revert用一个新提交来消除一个历史提交所做的任何修改。

revert与reset的区别

git revert是用一次新的commit来回滚之前的commit，git reset是直接删除指定的commit。
在回滚这一操作上看，效果差不多。但是在日后继续merge以前的老版本时有区别。因为git revert是用一次逆向的commit“中和”之前的提交，因此日后合并老的branch时，导致这部分改变不会再次出现，减少冲突。但是git reset是之间把某些commit在某个branch上删除，因而和老的branch再次merge时，这些被回滚的commit应该还会被引入，产生很多冲突。关于这一点，不太理解的可以看这篇文章。
git reset 是把HEAD向后移动了一下，而git revert是HEAD继续前进，只是新的commit的内容和要revert的内容正好相反，能够抵消要被revert的内容。