Git教程

次教程基于https://www.liaoxuefeng.com/wiki/

Git简介

集中式版本控制系统：版本库存放在中央服务器，用自己的电脑干活，类似于图书馆，必须互联网才能工作，CVS，SVN。

分布式版本控制系统：每个人的电脑都是一个完整的版本库，工作的时候不需要联网，安全性高的多

安装Git

在Linux上安装Git

首先，你可以试着输入git，看看系统有没有安装Git：

1
2
3

$ git
The program 'git' is currently not installed. You can install it by typing:
sudo apt-get install git

Debian或Ubuntu Linux，通过一条sudo apt-get install git就可以直接完成Git的安装，非常简单。

老一点的Debian或Ubuntu Linux，要把命令改为sudo apt-get install git-core，因为以前有个软件也叫GIT（GNU Interactive Tools），结果Git就只能叫git-core了。由于Git名气实在太大，后来就把GNU Interactive Tools改成gnuit，git-core正式改为git。

如果是其他Linux版本，可以直接通过源码安装。先从Git官网下载源码，然后解压，依次输入：./config，make，sudo make install这几个命令安装就好了。

在Mac OS X上安装Git

一是安装homebrew，然后通过homebrew安装Git，具体方法请参考homebrew的文档：http://brew.sh/。

第二种方法更简单，也是推荐的方法，就是直接从AppStore安装Xcode，Xcode集成了Git，不过默认没有安装，你需要运行Xcode，选择菜单“Xcode”->“Preferences”，在弹出窗口中找到“Downloads”，选择“Command Line Tools”，点“Install”就可以完成安装了。

在Windows上安装Git

从Git官网直接下载安装程序，然后按默认选项安装即可。

安装完成后，在开始菜单里找到“Git”->“Git Bash”，蹦出一个类似命令行窗口的东西，就说明Git安装成功！

安装完成后，还需要最后一步设置，在命令行输入：

1 2	$ git config --global user.name "Your Name" $ git config --global user.email "email@example.com"

因为Git是分布式版本控制系统，所以，每个机器都必须自报家门：你的名字和Email地址。

注意git config命令的--global参数，用了这个参数，表示你这台机器上所有的Git仓库都会使用这个配置，当然也可以对某个仓库指定不同的用户名和Email地址。

创建版本库

版本库又名仓库，repository，类似于一个目录，这个目录所有的文件都可以被Git管理起来，每个文件的修改、删除，Git都能追逐。

第一步、创建版本库

$ mkdir learngit
$ cd learngit
$ pwd
/Users/michael/learngit

如果你使用Windows系统，为了避免遇到各种莫名其妙的问题，请确保目录名（包括父目录）不包含中文。

第二步

通过git init命令把这个目录变成Git可以管理的仓库：

1 2	$ git init Initialized empty Git repository in /Users/michael/learngit/.git/

瞬间Git就把仓库建好了，而且告诉你是一个空的仓库（empty Git repository），细心的读者可以发现当前目录下多了一个.git的目录，这个目录是Git来跟踪管理版本库的，没事千万不要手动修改这个目录里面的文件，不然改乱了，就把Git仓库给破坏了。

如果你没有看到.git目录，那是因为这个目录默认是隐藏的，用ls -ah命令就可以看见。

把文件添加到版本库

Microsoft的Word格式是二进制格式，因此，版本控制系统是没法跟踪Word文件的改动的

因为文本是有编码的，比如中文有常用的GBK编码，日文有Shift_JIS编码，如果没有历史遗留问题，强烈建议使用标准的UTF-8编码，所有语言使用同一种编码，既没有冲突，又被所有平台所支持。

编写一个readme.txt文件

1 2	Git is a version control system. Git is free software.

一定要放到learngit目录下（子目录也行），因为这是一个Git仓库，放到其他地方Git再厉害也找不到这个文件。

把一个文件放到Git仓库只需要两步。

第一步，用命令git add告诉Git，把文件添加到仓库：

1	$ git add readme.txt

第二步，用命令git commit告诉Git，把文件提交到仓库：

$ git commit -m "wrote a readme file"
[master (root-commit) eaadf4e] wrote a readme file
 1 file changed, 2 insertions(+)
 create mode 100644 readme.txt

-m后面输入的是本次提交的说明，可以输入任意内容

git commit命令执行成功后会告诉你，1 file changed：1个文件被改动（我们新添加的readme.txt文件）；2 insertions：插入了两行内容（readme.txt有两行内容）。

为什么Git添加文件需要add，commit一共两步呢？因为commit可以一次提交很多文件，所以你可以多次add不同的文件，比如：

1
2
3

$ git add file1.txt
$ git add file2.txt file3.txt
$ git commit -m "add 3 files."

Git命令必须在Git仓库目录内执行

小结

初始化一个Git仓库，使用git init命令。

添加文件到Git仓库，分两步：

使用命令git add <file>，注意，可反复多次使用，添加多个文件；
使用命令git commit -m <message>，完成。

版本回退

如果修改文件

运行git status命令看看结果

git status命令可以让我们时刻掌握仓库当前的状态

git diff这个命令可以查看具体修改了哪些内容

$ git add readme.txt

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	modified:   readme.txt
	
$ git commit -m "add distributed"

HEAD指向的版本就是当前版本，回退版本时，Git只是改变指向，使用命令git reset --hard commit_id。

git reset --hard HEAD^
穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。

如果觉得输出信息太多--pretty=oneline
会看到commit id(版本号)Git是分布式控制系统，需要多人在同一个版本库中工作
要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。

工作区和暂存区

工作区：电脑中能看到的目录

版本库：

工作区有一个隐藏目录.git,就是Git的版本库
版本库中最重要的就是叫stage的暂存区，Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD

把文件往Git版本库里添加的时候，是分两步执行的：

第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；

第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。

因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。

管理修改

第一次修改 -> git add -> 第二次修改 -> git commit

第二次修改没有被提交

第一次修改 -> git add -> 第二次修改 -> git add -> git commit

如果不用git add到暂存区，那就不会加入到commit中。

撤销修改

git checkout -- file可以丢弃工作区的修改：

1	$ git checkout -- readme.txt

命令git checkout -- readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销，这里有两种情况：

一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；
一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。

git checkout -- file命令中的--很重要，没有--，就变成了“切换到另一个分支”的命令

用命令git reset HEAD <file>可以把暂存区的修改撤销掉（unstage），重新放回工作区

git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本。

小结

场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- file。

场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD <file>，就回到了场景1，第二步按场景1操作。

场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。

删除文件

当你删除了文件，Git知道你删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻告诉你哪些文件被删除了

现在你有两个选择，一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit

另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：

git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。

命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。

远程仓库

添加远程库

在github创建一个远程仓库，在本地仓库执行以下命令

1	git remote add origin git@github.com:1426768270/learngit.git

远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。

把本地库的所有内容推送到远程库上

1	$ git push -u origin master

把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。

由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。

从现在起，只要本地作了提交，就可以通过命令：

1	$ git push origin master

把本地master分支的最新修改推送至GitHub，现在，你就拥有了真正的分布式版本库！

SSH警告

当你第一次使用Git的clone或者push命令连接GitHub时，会得到一个警告：

1
2
3

The authenticity of host 'github.com (xx.xx.xx.xx)' can't be established.
RSA key fingerprint is xx.xx.xx.xx.xx.
Are you sure you want to continue connecting (yes/no)?

这是因为Git使用SSH连接，而SSH连接在第一次验证GitHub服务器的Key时，需要你确认GitHub的Key的指纹信息是否真的来自GitHub的服务器，输入yes回车即可。

Git会输出一个警告，告诉你已经把GitHub的Key添加到本机的一个信任列表里了：

1	Warning: Permanently added 'github.com' (RSA) to the list of known hosts.

这个警告只会出现一次，后面的操作就不会有任何警告了。

如果你实在担心有人冒充GitHub服务器，输入yes前可以对照GitHub的RSA Key的指纹信息是否与SSH连接给出的一致。

小结

要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git；

关联后，使用命令git push -u origin master第一次推送master分支的所有内容；

此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；

从远程库克隆

要克隆一个仓库，首先必须知道仓库的地址，然后使用git clone命令克隆。

1	$ git clone git@github.com:1426768270/gitskills.git

Git支持多种协议，包括https，但ssh协议速度最快。

分支管理

创建和合并分支

每次提交，Git会把它们串成一条时间线，这条时间线就是一个分支，master主分支，HEAD严格来讲不是指向提交，而是指向master，master才是指向提交，HEAD指向当前分支。

一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前。

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化

不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

实际的命令

创建dev分支，然后切换到dev分支

1	$ git checkout -b dev

git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：

1 2	$ git branch dev $ git checkout dev

然后，用git branch命令查看当前分支：

1	$ git branch

git branch命令会列出所有分支，当前分支前面会标一个*号。

然后，我们就可以在dev分支上正常提交，比如对readme.txt做个修改，然后提交

1 2	$ git add readme.txt $ git commit -m "branch test"

现在，dev分支的工作完成，我们就可以切换回master分支：

1	$ git checkout master

切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了！因为那个提交是在dev分支上

把dev分支的工作成果合并到master分支上

1	$ git merge dev

git merge命令用于合并指定分支到当前分支。

Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。

合并完成后，就可以放心地删除dev分支了

1	$ git branch -d dev

switch

我们注意到切换分支使用git checkout <branch>，而前面讲过的撤销修改则是git checkout -- <file>，同一个命令，有两种作用，确实有点令人迷惑。

实际上，切换分支这个动作，用switch更科学。因此，最新版本的Git提供了新的git switch命令来切换分支：

创建并切换到新的dev分支，可以使用：

1	$ git switch -c dev

直接切换到已有的master分支，可以使用：

1	$ git switch master

使用新的git switch命令，比git checkout要更容易理解。

小结

查看分支：git branch

创建分支：git branch <name>

切换分支：git checkout <name>或者git switch <name>

创建+切换分支：git checkout -b <name>或者git switch -c <name>

合并某分支到当前分支：git merge <name>

删除分支：git branch -d <name>

解决冲突

master分支和feature1分支各自都分别有新的提交，变成了这样

这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突

手动解决冲突后再提交。git status也可以告诉我们冲突的文件：

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存：

解决冲突之后重新提交

用带参数的git log也可以看到分支的合并情况

1	git log --graph --pretty=oneline --abbrev-commit

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。

解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。

用git log --graph命令可以看到分支合并图。

分支管理策略

合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

合并dev分支，请注意--no-ff参数，表示禁用Fast forward：

1	git merge --no-ff -m "merge with no-ff" dev

因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。

不使用Fast forward模式，merge后就像这样：

分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

Bug分支

每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

当你正在修复一个bug时，突然让你修复另外一个bug，旧的没法完成提交，利用Git的stash功能，把工作现场储藏起来。

git stash

git stash list命令查看工作现场

用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；

另一种方式是用git stash pop，恢复的同时把stash内容也删了

可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：

1	$ git stash apply stash@{0}

如果同样的bug要在dev上修复，只需要把同一样的修改复制到这个分支cherry-pick复制一个特定的提交到当前分支

1	git cherry-pick 4c805e2

小结

当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场；

在master分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick <commit>命令，把bug提交的修改“复制”到当前分支，避免重复劳动。

Feature分支

添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。

如果要丢弃一个没有被合并过的分支，可以通过git branch -D <name>强行删除。

多人协作

当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。

要查看远程库的信息，用git remote：

1 2	$ git remote origin

或者，用git remote -v显示更详细的信息

上面显示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。

推送分支

把该分支上的所有本地提交推送到远程库

1	git push origin master

如果要推送其他分支，比如dev，就改成：

1	git push origin dev

但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？

master分支是主分支，因此要时刻与远程同步；
dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

抓取分支

当另一个人要从远程库clone时，只能看见本地的master，必须创建远程origin的dev分支到本地

1 2	git clone git@github.com:1426768270/learngit.git git checkout -b dev origin/dev

当你的同伴向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送，会推送失败

Git提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送

指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：

1 2	$ git branch --set-upstream-to=origin/dev dev git pull

然后解决冲突，提交在push。

多人协作的工作模式通常是这样：

首先，可以试图用git push origin <branch-name>推送自己的修改；
如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
如果合并有冲突，则解决冲突，并在本地提交；
没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！

如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。

小结

查看远程库信息，使用git remote -v；
本地新建的分支如果不推送到远程，对其他人就是不可见的；
从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；
在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；
建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；
从远程抓取分支，使用git pull，如果有冲突，要先处理冲突。

Rebase

当多次push,pull后git的提交历史很乱，可以使用rebase把它变成一条干净的直线。

Git把我们本地的提交“挪动”了位置把本地分支放到最后

rebase操作可以把本地未push的分叉提交历史整理成直线；
rebase的目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比。

标签管理

发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。

Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针

创建标签

切换到需要打标签的分支上，git tag <name>

命令git tag查看所有标签

默认标签是打在最新提交的commit上的。有时候，如果忘了打标签需要找到历史提交的commit id

1	$ git tag v0.9 f52c633

标签不是按时间顺序列出，而是按字母排序的。可以用git show <tagname>查看标签信息

还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字

用命令git show <tagname>可以看到说明文字

小结

命令git tag <tagname>用于新建一个标签，默认为HEAD，也可以指定一个commit id；
命令git tag -a <tagname> -m "blablabla..."可以指定标签信息；
命令git tag可以查看所有标签。

操作标签

删除

1	git tag -d v0.1

因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。

如果要推送某个标签到远程，使用命令git push origin <tagname>：

1	git push origin v1.0

一次性推送全部尚未推送到远程的本地标签：

1	git push origin --tags

删除远程标签，先从本地删除

1	git tag -d v0.9

然后，从远程删除。删除命令也是push

1	git push origin :refs/tags/v0.9

小结

命令git push origin <tagname>可以推送一个本地标签；
命令git push origin --tags可以推送全部未推送过的本地标签；
命令git tag -d <tagname>可以删除一个本地标签；
命令git push origin :refs/tags/<tagname>可以删除一个远程标签。

自定义Git

让Git显示颜色，会让命令输出看起来更醒目

1	git config --global color.ui true

忽略特殊文件

在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件。

https://github.com/github/gitignore

GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了。

忽略文件的原则是：

忽略操作系统自动生成的文件，比如缩略图等；
忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件；
忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件

把.gitignore也提交到Git，就完成了！当然检验.gitignore的标准是git status命令是不是说working directory clean。

1	git add -f App.class

用-f强制添加到Git

用git check-ignore命令检查是那条规则忽略这个文件

1	git check-ignore -v App.class

# 排除所有.开头的隐藏文件:
.*
# 排除所有.class文件:
*.class

.*这个规则把.gitignore也排除了

1
2
3

# 不排除.gitignore和App.class:
!.gitignore
!App.class

把指定文件排除在.gitignore规则外的写法就是!+文件名，所以，只需把例外文件添加进去即可。

小结

忽略某些文件时，需要编写.gitignore；
.gitignore文件本身要放到版本库里，并且可以对.gitignore做版本管理！

配置别名

1	git config --global alias.* 命令

1
2
3

$ git config --global alias.co checkout
$ git config --global alias.ci commit
$ git config --global alias.br branch

--global参数是全局参数，也就是这些命令在这台电脑的所有Git仓库下都有用。

配置文件

每个仓库的Git配置文件都放在.git/config文件中：

$ cat .git/config 
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
    precomposeunicode = true
[remote "origin"]
    url = git@github.com:michaelliao/learngit.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
    remote = origin
    merge = refs/heads/master
[alias]
    last = log -1

当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig中