本篇参考廖雪峰老师的教程：https://www.liaoxuefeng.com/wiki/896043488029600

Git简介

Git是目前世界上最先进的分布式版本控制系统（没有之一）。

安装（Linux）

输入git查看是否安装；
安装之后进行进一步设置（因为Git是分布式版本控制系统，所以，每个机器都必须自报家门：你的名字和Email地址。）

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

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

初始化git仓库(git init)

在想要git管理的仓库对应的文件夹下，使用

git init

把这个目录变成Git可以管理的仓库
当前目录下多了一个.git的目录，这个目录是Git来跟踪管理版本库的。
如果你没有看到.git目录，那是因为这个目录默认是隐藏的，用ls -ah命令就可以看见。

把文件添加到git仓库

所有的版本控制系统，其实只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等等

首先在目录下创建一个文件readme.txt

git add

用git add命令，将文件添加到git仓库

git add readme.txt

git commit

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

git commit -m "wrote a readme file"

-m后面输入的是本次提交的说明

为什么要分两步走

可以多次add不同的文件，然后一次commit提交

时光机穿梭（git status, git diff）

添加并提交readme.txt后，修改了文件内容，然后运行git status，这个命令可以告诉我们文件被修改了，但是还没有提交修改

可以使用git diff查看具体修改了什么内容

版本回退

显示提交日志（git log（ --pretty=oneline））

git log命令显示从最近到最远的提交日志

加上--pretty=oneline选项，即git log --pretty=oneline可以查看精简的提交日志

版本表示

HEAD：当前版本
HEAD^：上一个版本
HEAD^：上上个版本
……
HEAD~100：上100个版本

版本回退（git reset, git reflog）

以回退到上一个版本为例：

git reset --hard HEAD^

此时使用git log查看版本库的状态，发现最新的版本已经看不到了

如果想要恢复最新的版本，可以使用其commit id：

git reset --hard 1094a

版本号不需要写全，写出前几位就行

Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把HEAD从指向别的版本，然后顺便把工作区的文件更新了。

但是如果不记得commit id，可以通过git reflog查看命令历史，确定要回到未来的哪个版本

工作区和暂存区

工作区

就是电脑里能看到的目录

版本库

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

前面讲了我们把文件往Git版本库里添加的时候，是分两步执行的，如上图：

• 第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；
• 第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。

可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。

管理修改

问：为什么Git比其他版本控制系统设计得优秀？
答：因为Git跟踪并管理的是修改，而非文件。

每次修改，如果不用git add到暂存区，那就不会加入到commit中，git commit只负责提交暂存区内的修改

查看工作区和版本库里面最新版本的区别，以readme.txt为例：

git diff HEAD -- readme.txt

撤销修改（git checkout, git reset）

撤销工作区的修改（git checkout --）

git checkout -- file

可以丢弃工作区的修改，将file在工作区的修改全部撤销，有两种情况：

• file修改后没有被放到暂存区，checkout后就回到和版本库一模一样的状态
• file添加到暂存区之后才做了修改，checkout后就回到添加到暂存区后的状态

撤销暂存区内的修改

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

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

然后就可以使用git checkout丢弃工作区的修改了。

撤销本地版本库内的修改

参考“版本回退”一节的内容，回退到上一个版本

撤销远程版本库内的修改

做梦吧……

删除文件

在Git中，删除也是一个修改操作

如果直接在文件管理器中把文件删了，工作区和版本库就不一致了，会在git status命令中体现出来。

这时有两种选择：

从版本库中删除文件

git rm + git commit

恢复误删文件

git checkout -- test.txt

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

注意：从来没有被添加到版本库就被删除的文件，是无法恢复的！

远程仓库

GitHub提供Git仓库托管服务，只要注册一个GitHub账号，就可以免费获得Git远程仓库。

• 创建SSH key

在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。

如果没有，创建SSH key：

ssh-keygen -t rsa -C "youremail@example.com"

之后可以在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。

• 登录GitHub

打开“Settings”，“SSH and GPG keys”页面，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容，点“Add Key”，就应该看到已经添加的Key。

为啥需要SSH key？GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。

GitHub允许添加多个Key

友情提示：在GitHub上免费托管的Git仓库，任何人都可以看到（但只有你自己才能改）。

如果不想让别人看到：

• 氪金，让GitHub把公开的仓库变成私有的，这样别人就看不见了（不可读更不可写）
• 自己搭一个Git服务器，因为是你自己的Git服务器，所以别人也是看不见的。

添加远程库

情景：你已经在本地创建了一个Git仓库后，又想在GitHub创建一个Git仓库，并且让这两个仓库进行远程同步，这样，GitHub上的仓库既可以作为备份，又可以让其他人通过该仓库来协作

创建新的远程仓库

首先，登录GitHub，然后点击右上角“Create a new repo”按钮，创建一个新的仓库
在Repository name填入名称，其他保持默认设置，点击“Create repository”按钮，就成功地创建了一个新的Git仓库

目前，在GitHub上的这个仓库还是空的，但我们

• 可以从这个仓库克隆出新的仓库，
• 也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitHub仓库。

将一个已有的本地仓库与远程仓库关联

根据GitHub的提示，在本地的对应仓库下运行命令：

git remote add origin git@github.com:GitHub_account/respository_name.git

关联一个远程库时必须给远程库指定一个名字，origin是默认习惯命名

把本地库的所有内容推送到远程库上（git push）

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

git push -u origin master

用git push命令，实际上是把当前分支master推送到远程。

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

此后在本地做了修改后

只需要运行

git push origin master

就可以把本地master分支的最新修改推送至GitHub

SSH警告

删除远程库（git remote rm）

如果添加的时候地址写错了，或者就是想删除远程库，可以用git remote rm <name>命令。

查看远程库信息

使用前，建议先用git remote -v查看远程库信息

根据名字删除

此处的“删除”其实是解除了本地和远程的绑定关系，并不是物理上删除了远程库。远程库本身并没有任何改动。要真正删除远程库，需要登录到GitHub，在后台页面找到删除按钮再删除。

从远程库克隆

情景：假设我们从零开发，那么最好的方式是先创建远程库，然后，从远程库克隆。

创建一个新的仓库

创建时勾选Initialize this repository with a README，这样GitHub会自动为我们创建一个README.md文件。创建完毕后，可以看到README.md文件

克隆一个本地库

git clone git@github.com:michaelliao/gitskills.git

如果有多个人协作开发，那么每个人各自从远程克隆一份就可以了。

git支持多种协议

你也许还注意到，GitHub给出的地址不止一个，还可以用https://github.com/michaelliao/gitskills.git这样的地址。

实际上，Git支持多种协议，默认的git://使用ssh，但也可以使用https等其他协议。但ssh速度最快。

使用https除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令，但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。

分支管理

分支就是科幻电影里面的平行宇宙
分支合并：

分支的实际用处：你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

Git的分支无论创建、切换和删除分支，在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。

创建与合并分支

master分支

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

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

创建新的分支

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

git checkout -b dev

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

git branch dev
git checkout dev

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

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

在新分区上的修改和提交

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

例如修改readme.txt之后：

git add readme.txt 
git commit -m "branch test"

提交完修改后，切回master分支

git checkout master

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

合并分支

git merge dev

最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

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

当然，也不是每次合并都能Fast-forward，我们后面会讲其他方式的合并。

Git合并分支也很快！就改改指针，工作区内容也不变！

删掉分支

合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，

git branch -d dev

删掉后，我们就剩下了一条master分支

Switch

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

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

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

git switch -c dev

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

git switch master

小结

因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。

查看分支：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>

解决冲突

设想出现了下面的情况：

解决流程

git merge feature1会提示存在冲突
git status可以告诉我们冲突的文件

直接查看readme.txt的内容，Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，然后进行修改并保存。

提交之后变成下面的样子：

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

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

最后，删除feature1分支

小结

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

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

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

分支管理策略

通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
如果要强制禁用Fast-forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

--no-ff方式的git merge实战

git switch -c dev

修改readme.txt：

git add readme.txt 
git commit -m "add merge"

切换回master：

git switch master

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

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

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

用git log看看分支历史，可以看到不使用Fast forward模式，merge后就像这样：

分支策略

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

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

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

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

BUG分支

在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

储存并恢复当前分支

当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，当前正在dev上进行的工作还没有提交（工作未完成，还不能提交）

储存分支

Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

git stash

修复完bug（过程省略）后，接着回到dev分支干活

恢复分支

使用git stash list命令查看：

git stash list
stash@{0}: WIP on dev: f52c633 add merge

工作现场还在，Git把stash内容存在某个地方了，需要恢复一下

两种恢复方式

• 一是用git stash apply恢复，但是恢复后，stash内容并不删除，需要用git stash drop来删除
• 另一种方式是用git stash pop，恢复的同时把stash内容也删了

恢复指定的stash

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

git stash apply stash@{0}

在不同的分支上修复相同的bug（cherry-pick）

在master分支上修复了bug后，我们要想一想，dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。

那怎么在dev分支上修复同样的bug？

同样的bug，要在dev上修复，我们只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。

先切换到dev分支，然后执行：

git cherry-pick 4c805e2

反之，直接在dev分支上修复bug，然后在master分支上“重放”也可以，但是需要git stash命令保存现场，才能从dev分支切换到master分支。

Feature分支

软件开发中，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。

git switch -c feature-vulcan

开发ing

git add vulcan.py
git status
git commit -m "add feature vulcan"

切回dev分支，准备合并

git switch dev

正常来讲，应该合并然后删除。

但是此时突然需要取消新功能，试图执行

git branch -d feature-vulcan

失败了

Git友情提醒，feature-vulcan分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用大写的-D参数。

强行删除

git branch -D feature-vulcan

删除成功

多人协作

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

查看远程库的信息

要查看远程库的信息，用git remote
或git remote -v显示更详细的信息
会显示可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。

推送分支

就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：

操作

git push origin master

若推送dev分支：

git push origin dev

哪些分支需要推送呢

• master分支是主分支，因此要时刻与远程同步；

• dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；

• bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；

• feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

抓取分支

当从远程库clone时，默认情况下，只能看到本地的master分支。

如果合作者想要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是用这个命令创建本地dev分支：

git checkout -b dev origin/dev

然后就可以在dev上继续修改，然后把dev分支push到远程（add commit push三件套）

推送分支冲突

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

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

设置本地分支与远程分支的链接

git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：

git branch --set-upstream-to=origin/dev dev

再push就成功了。但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push

小结：多人协作的工作模式

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

Rebase

标签管理

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

Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的。

Git有commit，为什么还要引入tag？tag就是一个让人容易记住的有意义的名字，它跟某个commit绑在一起。

创建标签

打标签

首先，切换到需要打标签的分支上，然后输入：

git tag <name>

就可以打上一个新标签

查看所有标签

git tag

补打标签

找到历史提交的commit id，然后打上就可以了

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

git tag v0.9 <commit id>

再用命令git tag查看标签

标签不是按时间顺序列出，而是按字母排序的。

查看标签信息

可以用git show <tagname>查看标签信息

创建带有说明的标签

 git tag -a v0.1 -m "version 0.1 released" 1094adb

注意：标签总是和某个commit挂钩。如果这个commit既出现在master分支，又出现在dev分支，那么在这两个分支上都可以看到这个标签。

操作标签

删除本地标签

git tag -d v0.1

推送某个标签到远程

git push origin <tagname>

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

git push origin --tags

删除远程标签

• 先从本地删除：git tag -d v0.9
• 然后从远程删除：git push origin :refs/tags/v0.9

使用GitHub

参与一个开源项目

访问项目主页

Fork

在自己的账号下克隆了一个项目仓库

从自己的账号下clone

一定要从自己的账号下clone仓库，才能推送修改。如果从bootstrap的作者的仓库地址git@github.com:twbs/bootstrap.git克隆，因为没有权限，你将不能推送修改。

如果你想修复bootstrap的一个bug，或者新增一个功能，立刻就可以开始干活，干完后，往自己的仓库推送。

如果你希望bootstrap的官方库能接受你的修改，你就可以在GitHub上发起一个pull request。当然，对方是否接受你的pull request就不一定了。

使用Gitee

使用GitHub时，国内的用户经常遇到的问题是访问速度太慢，有时候还会出现无法连接的情况，可以使用国内的Git托管服务——Gitee

一个本地库能不能既关联GitHub，又关联Gitee呢？
答案是肯定的，因为git本身是分布式版本控制系统，可以同步到另外一个远程库，当然也可以同步到另外两个远程库。

使用多个远程库时，我们要注意，git给远程库起的默认名称是origin，如果有多个远程库，我们需要用不同的名称来标识不同的远程库。

自定义git

让git显示颜色

git config --global color.ui true

忽略特殊文件

有些时候，你必须把某些文件放到Git工作目录中，但又不能提交它们，比如保存了数据库密码的配置文件啦，等等

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

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

忽略文件的原则

• 忽略操作系统自动生成的文件，比如缩略图等；

• 忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件；

• 忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件。

强制添加被.gitignore忽略的文件

用-f选项：

git add -f App.class

查找.gitignore写作的问题

git check-ignore -v App.class

需要把.gitignore也提交到版本库

配置别名

搭建git服务器

使用SourceTree