前言和概述

 本教程是廖雪峰的官方网站中的Git教程的完整笔记
 
 https://www.liaoxuefeng.com/wiki/896043488029600
 
 
 笔记本身遵循个人的笔记习惯，具体而言：
 1. 笔记会做到基本完整记录书中所有知识点不会有任何遗漏
 2. 章节遵照原书排序
 3. 章标题用markdowns的2号标题
 4. 每两大章之间用横线分隔
 5. 节标题使用和正文一样的字号，节标题末尾带一个冒号：
 6. 知识点依附在具体的节之下，用序号标记顺序
 7. 知识点基本遵循先后出现的顺序
 8. 中文方括号【】中的内容是自己的注释，一般是我本人的批注和想说的话
 9. 圆括号（）是一些对较抽象或复杂内容的提示性文字

总之就是，同样的项目，git同时维护了工作区版本、暂存区版本和版本库头版本三份项目，这种维护是从逻辑上维护的而非存储了全部的文件，做到这一点是从设计上只存储对每个文件的修改而非存储全量的所有文件，运行的时候，只有工作区是一份完整的项目文件，程序员对工作区内的项目文件进行新的编辑，然后提交到暂存区，此时git会计算修改然后被提交到暂存区的不是文件而是修改，最后从暂存区发射命令，一次性把暂存区中的修改正式提交到版本库。

最后，所学的这些命令基本就是对工作区、暂存区、版本库的增删改查

Git简介

Git的诞生：

1. git的发展历史沿革：从1991年开始，手工合并11年，用BitKeeper管理3年，然后闹掰写出了git

   1. 1991年：Linus创建了开源linux系统

   2. 2002年之前：世界各地开源贡献者手动发送给Linus，Linus用一个叫diff的文本差异比较软件手工合并代码，因为那时Linus反对当时的集中式版本控制系统例如CVS和SVN，这又是因为这种软件速度慢而且必须联网的缺点，总之就是不好用

   3. 2002年到2005年：由于代码实在太庞大无法继续手工合并，社区给了Linus压力，Linus找到商业版本控制系统软件开发公司BitMover公司，让Linux社区获得了免费使用BitKeeper软件的权限

   4. 2005年，社区里一个叫Andrew的尝试破解BitKeeper软件然后被发现，BitMover公司要求收回对Linux社区的免费使用权限→Linux不道歉，花了2周时间用C写了一个分布式版本控制系统Git

集中式vs分布式：

1. 集中式版本控制系统：一种版本控制系统的分类。

   1. 集中式版本控制系统的工作方式：版本库（软件所有版本的集合）集中存放在中央服务器，程序员编码则使用自己的电脑，每次写代码之前先从中央服务器同步下来最新的版本，然后写代码，写完了代码把本地的版本推送到中央服务器。

   2. 集中式版本控制系统的缺点：必须联网才能工作，在互联网上，网速慢的话提交文件很痛苦。

2. 分布式版本控制系统：一种版本控制系统的分类。

   1. 分布式版本控制系统的工作方式：每个人的电脑上存放一个完整的版本库（软件所有版本的集合），写代码的话直接就着本地的版本库开写，多人协作的话就互相把对文件的修改推送给协作编码的所有人

   2. 分布式版本控制系统的的优点：相比于集中式版本控制系统会安全一些，因为所有协作者的电脑都存储了完整的版本库，任一人的电脑坏掉，只需要把别人的版本库复制过来即可，但集中式版本控制系统的中央服务器如果出问题基本这项目就告别了

   3. 实际中分布式版本控制系统也需要一个用于交换修改之处的中央服务器：实际中，很少让项目中协作者进行端到端互相推送这种事情，一般会设定一个中央服务器，用于交换修改，和集中式版本控制系统的区别是每次编码之前不用先从中央服务器上同步下才能开始工作，直接可以开始干活，而且哪怕没有用于交换的中央服务器，也照样可以协作，只是交换修改会不太方便

3. CVS：一种开源、免费的集中式版本控制系统。最早的集中式版本控制系统，至今还有人使用，但是本身有一些问题，容易提交文件不完整，版本库莫名损坏

4. SVN：一种开源、免费的集中式版本控制系统。比CVS好在稳定得多，在集中式版本控制系统中份额最大

5. ClearCase：一种收费的集中式版本控制系统。IBM公司从Rational公司手里收购而来，缺点非常突出，安装包比windows还大，运行比蜗牛还慢，只有比较人傻钱多的那种世界500强会用

6. VSS：一种集中式版本控制系统。微软开发的集中式版本控制系统，在Visual Studio中内置，但不好用，连微软自己都不用

7. 常见的分布式版本控制系统：Git、BitKeeper、Mercurial、Bazaar

安装Git

1. 名字和电子邮箱：安装Git所必须执行的最后一步。

   1. 名字和电子邮箱的作用：用于分布式版本控制系统用于自报家门，但也不用担心被冒充

   2. 可以对不同仓库分别指定名字和电子邮箱：可以对不同仓库分别指定名字和电子邮箱

创建版本库

1. 版本库：受GIt追踪的用于存储项目的仓库。

2. 修改：git中的一个单位。对文件的一次增删改就算作一次修改。

3. Git究竟追踪了版本库的什么：追踪修改。这也是为什么Git比其他版本控制系统设计得优秀的原因，其追踪修改而非追踪文件

4. 创建版本库的步骤：

   1. 命令行cd到版本库根目录下

   2. 初始化版本库根目录为受Git追踪的仓库：git init

   此时版本库根目录会多出一个叫.git的隐藏子文件夹，其用于跟踪版本库

5. Git只能追踪文本文件的修改：包括git在内的所有版本控制系统，能够被追踪修改的只有文本文件，即二进制文件的修改不可被追踪【想想也知道视频或图片文件肯定无法被字符级追踪】，而且具体而言，是以行为单位，跟踪具体的某一文件某一行号的修改

6. Word文件是二进制格式文件：值得注意的是word文件不属于文本文件，而是一种二进制文件，所以word文件不能被git追踪

7. 建议使用UTF-8文本编码：标准编码，支持万国语言

8. 不要使用windows自带的记事本对文本文件进行编辑：windows自带的记事本会为每个被编辑的文件开头增加一行，这行只有一个0xefbbbf字符，，造成的问题一般有1. 网页第一行显示一个问号；程序编译报错

9. 把文件同步到本地版本库操作：

   1. 把readme.txt文件添加入暂存区：git add 文件名1 文件名2 文件名3
      在把文件和文件修改提交到版本库之前设定一个暂存区的目的是，你可以add很多个文件，然后下一步一次性提交到版本库，例如上述示例中就add了三个文件

      这一步如果成功会没有任何提示因为Unix哲学是“没有任何消息就是好消息”

   2. 把文件提交到本地版本库：git commit -m “wrote a readme file”

      其中-m属性及其后面的字符串参数，是指对本次提交的文字说明，必须写，但是有办法可以不写，但最好还是每次写一下

      这一步如果成功将会打印仓库变动的一份简略报告，例如3 file changed是三个文件被修改，2 insertions是插入了2行新的内容

10. 一次性把根目录塞到暂存区的操作：git add .

时光机穿梭

时光机穿梭：

1. 查看当前工作区【git相对其它版本控制系统的一个独特概念。工作区就是版本库根目录下除了.git文件夹下的所有目录和文件】的状态操作：git status

   这个目录将会打印当前仓库的状态信息，包括在哪个分支里、是否存在已修改但未提交到版本库的修改（以及具体是哪些文件被修改了），示例如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

$ git status

On branch master

Changes not staged for commit:

(use "git add <file>..." to update what will be committed)

(use "git checkout -- <file>..." to discard changes in working directory)

modified: readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

2. 查看某文件的修改情况：git diff 文件名

   会以unix通用的diff格式打印出文件的修改情况

版本回退：

1. 查看本地版本库提交记录：git log

   这个命令将会打印所有的commit的提交记录，包括每次commit的版本号（十六进制哈希编码）、每次commit的作者是谁、日期时间、commit时的的注释

2. 版本号使用哈希编码的原因：对集中式版本控制系统SVN而言commit id是顺序的1、2、3编号，但分布式版本控制系统由于是分布式协作，所以必须使用哈希来给每一次提交编号，防止不同的人的不同提交却使用同样的提交号

3. 版本号的相对缩写法：

   1. HEAD：HEAD表示当前的最新的版本

   2. 幂符号：HEAD后每加一个幂符号^表示第前一个版本，即HEAD^表示上个版本，HEAD^^表示第前两个版本

   3. 幂数：HEAD可以直接用幂数标注“第前多少个版本”，即HEAD^100表示第前100个版本

4. 回退版本库中的头版本操作：git reset –hard 版本号

   注意这里可以用版本号的相对缩写法也可以直接写出版本号，例如git reset –hard HEAD^，或者git reset –hard 1094a，直接写版本号写前几个十六进制数字即可，git会自动搜索

5. 打印所有历史git命令历史记录：git reflog

   这个命令会记录所有的记录

6. 版本回退如果后悔了：用之前的版本号reset命令回去。如果关掉了终端导致丢失了之前的版本号，可以用git reflog命令查看一下记录，里面会有曾经从哪个先进版本号回退到哪个过去版本号的记录

7. 版本回退的速度：版本回退速度很快，因为原理上只是把指向当前版本的HEAD指针往过去的版本指回去即可

工作区和暂存区：

1. 工作区：git相对其它版本控制系统的一个独特概念。工作区就是版本库根目录下除了.git文件夹下的所有目录和文件

2. 版本库：git中的一个文件夹的名字。隐藏文件夹.git就是版本库，版本库就是git下一个文件夹的名字。版本库中存储的主要内容是1. 暂存区stage；2. master分支；3. 指向master分支的指针HEAD

3. 暂存区/stage：版本库中的主要内容之一，又名index。工作区中项目的修改被add命令会先添加到暂存区，暂存区的内容会在commit命令后被提交到master分支中

管理修改：

撤销修改：

1. 回退工作区中对文件的修改操作：git checkout – 文件名

   把工作区中已被编辑修改但还没add命令到暂存区中的指定文件，回退到暂存区中的版本，如果暂存区中没有这个文件的新版本就回退到上一次commit的文件版本

   这个命令可以用于误删工作区中的文件，从版本库的头版本中恢复

2. 回退暂存区中对文件的修改操作：git reset HEAD readme.txt

   这是也是和“回退版本库中的头版本”操作一样使用了reset命令【“回退版本库中的头版本”操作的命令是git reset –hard 版本号】，即这个命令既可以用于版本库也可以用于暂存区。对暂存区使用reset命令后，暂存区中对文件的修改并不会丢失，而是向后回退到工作区文件

删除文件：

1. 删除版本库中头版本中的文件：git rm 文件名

远程仓库

远程仓库：

1. 在github上设置SSH相关：本地git与github之间一般使用SSH协议进行数据传输，所以需要在github上设置一下你的个人计算机的非对称加密公钥以便建立SSH连接

   1. 如果没有id_rsa和id_rsa.pub文件：找找你的电脑里的本用户目录的.ssh文件夹，一般这个文件夹下会有两个文件id_rsa和id_rsa.pub，这一个是非对称加密私钥一个是非对称加密公钥，如果没有的话创建一对就行，命令是在.ssh目录下运行ssh-keygen -t rsa -C “邮箱字符串”

   2. 在github上添加SSH key：登录github，打开account settings里的SSH Keys，把你的id_rsa.pub文件里的字符串全部粘贴进去就行，标题就是给这串公钥起个名，然后保存

添加远程库：

1. 远程库原理：让你本地电脑与github公司的服务器电脑结成分布式端到端连接，不仅可以让github服务器上的版本作为项目的备份，还能方便他人也通过github服务器结成分布式端到端连接，进行项目协作，其它基于git的代码托管平台同理

2. 与github上的项目仓库远程库进行远程分布式端到端连接操作：git remote add 本地给远程仓库起的名 git@github.com:github账号username/github仓库名.git

   例如git remote add origin git@github.com:michaelliao/learngit.git，就是把本地版本库与github账号michaelliao的learngit仓库进行了远程连接，这个远程仓库在本地设定为名字origin

3. git使用ssh连接远程仓库：git连接本地版本库与远程仓库的原理是使用ssh

4. 把本地版本库上的头版本推送到远程库操作：git push -u origin master

   把本地的master分支头版本推送到起名为origin的远程仓库。因为git使用ssh连接远程仓库的缘故，如果第一次使用这个命令的时候有可能会弹出ssh警告，询问是否进行连接，这本质上是询问是否进行ssh连接，输入yes或者no即可，输入yes就会把github给的非对称加密公钥添加到本地信任列表

   -u参数的功能是把本地的master分支与远程的master分支进行关联，这种关联在第一次使用push命令的时候需要指定，在以后则可以进行省略，即第一次运行的时候是git push -u origin master，以后只需要git push origin master

5. 查看所有的分布式端到端连接到的远程库操作：git remote -v

6. 删除本地已完成分布式端到端连接的某远程库的连接操作：git remote rm 远程库名

   例如git remote rm origin就是把本地版本库对远程库origin的连接删掉，即解除本地版本库对远程库的绑定关系

从远程库克隆：

1. 使用ssh协议把远程库里的头版本克隆到本地工作区操作：git clone git@github.com:github账号username/github仓库名.git

   例如，git clone git@github.com:michaelliao/gitskills.git，就是把github账号michaelliao的learngit仓库里的头版本克隆到本地工作区

   上述的git@格式的是进行ssh连接，github支持多种协议例如https，但https坏处是速度慢，而且每次推送必须输入一次密钥，当然好处是有些公司用服务器是禁止ssh端口的，只能使用ssh之外的协议

分支管理

分支管理：

1. SVN系统的分支管理功能的缺点：创建和切换分支巨慢让人无法忍受

创建与合并分支：

1. HEAD指针指向的版本是什么：指向当前分支的头版本指针的指针

2. 分支是什么：git中每次commit都会构造一个新的项目头版本，随着版本不断更新，头版本和旧版本穿成一条链，这条链就叫分支，每个分支附带一个指向该分支头版本的指针

3. 创建一个新分支我们在创建什么：新分支创始之初，是创建了一个新的指向头版本的指针，你可以让HEAD指针指向这个新指针，然后每次commit的新版本会更新在这个新指针上，随着你在新的分支头版本指针上不断commit添加新版本，这个新的分支就跟着分支头版本指针越走越长

4. 创建新分支操作：git branch 新分支名

5. 切换到某分支操作：git checkout 分支名

6. 创建新分支加切换到新分支融合快捷操作：git checkout -b 新分支名

   -b参数就是这个创建并切换的操作

7. 打印所有分支操作：git branch

   这个命令会列出所有分支，并且在当前commit欲更新版本的分支的名字之前打出星号*

8. 把指定分支名的头指针指向当前分支的头指针（分支合并）操作：git merge 分支名

   这个操作会重定向指定的分支头指针，将其指向当前分支头指针，所有的修改会被融合

9. 删除分支：git branch -d 分支名

   之后还有个强制删除分支的命令

10. 分支的用法：无论是在github上协作还是自己写项目，我们先自己弄一个分支，并且在这个分支上更新版本，最后去申请分支合并（即申请把github服务器上的项目仓库的HEAD指针指向自己的分支头版本指针）或自己进行分支合并，然后把为了完成任务创建的新分支删掉，这样会相比直接在master分支上工作安全。

11. switch命令：新版git觉得切换到某分支操作用checkout命令（切换到某分支操作：git checkout 分支名）以及回退工作区中对文件的修改操作也用checkout命令（回退工作区中对文件的修改操作：git checkout – 文件名）都共用checkout命令是令人迷惑的，因此新版本把切换分支单独开了个命令叫switch：

12. switch切换到某分支操作：git switch 分支名

13. switch创建新分支加切换到新分支融合快捷操作：git switch -c 新分支名

解决冲突：

1. 冲突：两个分支如果都修改同一个文件后，对这两个分支进行分支合并操作，产生的一种冲突现象。具体而言，现在有两个分支，我们知道git跟踪的是修改，而且跟踪的是对行号的文本修改，那么如果两个不同分支都对同一个文件的相同行号进行了修改，然后分别对这两个分支进行了add和commit，正常而言两个分支的头指针都会往前延伸一个新版本，此时如果你尝试对两个分支进行分支合并（把指定分支名的头指针指向当前分支的头指针（分支合并）操作：git merge 分支名。这个操作会重定向指定的分支头指针，将其指向当前分支头指针），由于两个分支的这个相同文件的相同行号的修改内容不同，就会产生分支无法合并的冲突。

   如下是一个典型的冲突，有两个分支，feature1和master，都分别对同一文件进行不同修改，提交成了两个不同的版本，此时HEAD指针指向master，如果尝试合并feature1和master，就会产生冲突

   

2. 如何解决冲突：尝试分支合并如果出现冲突，git会提示无法合并，并给出是哪个文件的什么内容出现了冲突，此时很简单手动处理即可，即把其中一个分支的冲突文件的冲突行改成和另一个分支一样就可以正常进行分支合并操作了

3. 查看分支合并图操作：git log –graph

   使用这个命令将会看见分支合并的字符示意图

分支管理策略：

1. fast forward：git的默认分支合并模式，又快速合并模式。快速的同时，分支合并后，会丢失其中一个分支的分支信息，即忘掉自己是从之前哪个分支合并而来的

2. 强制禁用fast forward的分支合并操作：git merge –no-ff -m “merge with no-ff” 分支名

   其中–no-ff参数是指强制禁用fast forward。强制禁用fast forward进行分支合并会在合并的时候生成并commit一个新的版本，这样就可从分支历史上可以看出分支信息而不会丢失掉被合并的分支信息，也因为创建了一个新的版本并commit，所以需要加入-m参数并写入新版本的commit注释

3. 分支管理策略：实践中，经常被遵循的几个基本的分支管理策略

   1. master：master分支仅用于发布新版本，即不用于写新的代码

   2. dev：写新的代码的干活分支你就命名为dev就比较好，每次写完就合并丢弃掉

   3. 多人协作：如果多人协作写新的代码，那么你们都拥有自己的干活分支，然后集体往dev分支上合并自己的新代码，最后需要发布新版本的时候统一一次性把dev合并到master

Bug分支：

1. 项目有bug怎么办：开一个新的临时分支，然后在临时分支上编写新的代码修复bug，完成之后合并分支，把临时分支删掉

2. 如果正在开发一个新的feature到一半还不想去正式add并commit本次的半成品代码，这时候需要紧急修复一个恶性bug：使用gut的stash（贮藏）功能

3. stash：github提供的功能之一，功能是存档并回撤当前的工作区+暂存区修改，执行之后工作区将会回到上一个commit版本

   这个操作的意义其实是用于一个分支的工作还没做完时，不想去正式add和commit半成品代码，却由于另一个紧急任务需要开辟新的分支，那就先把当前分支给贮藏，然后开新分支完成紧急任务并合并掉，再通过恢复贮藏操作，恢复原先还没完成的半成品代码，注意，如果紧急任务是修复bug，那么你恢复贮藏的时候会回退到有bug的版本，因此可以配合执行一个“复制特定commit的所有修改到当前分支”操作，以把你用于修复bug的代码复制到你恢复贮藏后的还未完成工作的半成品版本当中

4. 贮藏操作：git stash

5. 打印所有贮藏的列表操作：git stash list

   这个命令将会打印出所有的贮藏的列表，贮藏名是stash@{0}格式的

6. 单纯恢复某指定贮藏操作：git stash apply 贮藏名

   这个命令不会删掉贮藏本身

   如果你只有一个贮藏，那么不用写贮藏名也可以，git知道你只有一个可恢复的贮藏

7. 删除某指定贮藏操作：git stash drop

8. 恢复并删除某指定贮藏操作：git stash pop

9. 复制特定commit的所有修改到当前分支操作：cherry-pick

   这个操作本质是一次自动commit，因此当前分支的头版本会commit并前进一个含有被复制代码的新版本

Feature分支：

1. 强制删除某指定分支操作：git branch -D 分支名

   之所以会有强制删除一说，是因为如果某分支的修改从未被合并到任何其它分支就面临删除，此时如果执行删除会彻底丢失掉在这个分支上的所有工作，git不会允许你直接删除

   不过听说根本就不存在彻底丢弃任何工作的场景，因为以防万一

多人协作：

1. 查看远程仓库的信息操作：git remote

2. 查看所有远程仓库的详细信息操作：git remote -v

   注意这个命令会在行末的括号里分别显示具有可以抓取和推送权限的远程仓库，如下图

   

3. 推送本地指定分支的头版本到指定远程仓库：git push 指定远程仓库名 指定分支名

   本地的默认远程仓库名称是origin

4. 多人协作下的远程仓库推送冲突及解决办法：如果你和协作者都对同一文件进行了修改工作，对方先把对方的修改工作推送到了远程仓库的dev分支，此时你再尝试把自己对这个文件的修改工作推送到远程仓库的dev分支将会失败，解决办法先把自己本地的dev分支与远程仓库的dev分支进行同步，即把协作者的最新修改工作下载到你的本地dev分支，再本地将你的修改工作分支与你本地的dev分支合并，此时推送你本地的dev分支将不再冲突

Rebase：

1. rebase的应用场景：基于之前的版本开发了一个新版本尚未提交上去时，之前的版本已经前进了两个版本，此时我们想提交我们开发的版本，但出于某种原因，我们需要基于最新的头版本提交我们开发的新的版本，而不是基于之前的版本（比如我们需要依赖新版本的几个特性），那么可以先从远程仓库把最新版本拉下来，然后执行rebase命令，这会重新指定基版本，然后再提交就行

2. rebase操作：git rebase

3. rebase的实质原理：实际上是把你基于之前版本的那些修改数据给丢弃掉了，但在此之前，会先自动创建一些基于较新版本的内容一样的新的修改

标签管理

标签管理：

1. 标签：commit的时候一同被提交的一个类似备注的数据结构。我们有了备注还要标签，是因为这个标签的作用是作为commit id的别名，一般是用来写版本号的，比如v1.2之类的

创建标签：

1. 给当前分支的最新版本打标签操作：git tag 标签名

   这个标签名一般就是v1.0之类的

2. 给当前分支的指定版本打标签操作：git tag 标签名 版本号

   此处版本号也可以使用版本号的相对缩写法

3. 查看所有标签列表操作：git tag

   注意这里的列表是按字母顺序排列，而非时间顺序

4. 给当前分支的指定版本打标签顺便写评论操作：git tag -a 标签名 -m “评论字符串” 版本号

5. 查看指定标签的详细信息操作：git show 标签名

操作标签：

1. 删除标签操作：git tag -d 标签名

2. 推送指定标签到远程仓库操作：git push 远程仓库名 标签名

3. 推送所有标签到远程仓库操作：git push origin –tags

4. 删除远程仓库的指定标签：先删除本地标签，然后git push origin :refs/tags/标签名

使用GitHub

使用GitHub：

1. 如何参与他人的开源社区项目：先把其他的开源项目的仓库fork一下到自己的账户名下，这样自己名下就有一个同样的该远程仓库了，然后把本地个人计算机与自己的账户名下的该远程仓库进行连接和clone，接下来对准自己的账户名下的该远程仓库进行工作即可，如果觉得完成了工作就发起一个pull request，如果对方接受，就会把你的工作合并到官方

使用Gitee

自定义Git

自定义Git：

1. 自定义Git是什么：git作为一个软件，有很多可配置的本地个性化可配置项

2. git本身的配置文件在哪：

   1. 对每个项目，其git的配置文件在该项目根目录，即.git/config

   2. 对当前用户，即所有项目，其git配置文件在用户主目录下，即~/.gitconfig

3. 让Git的终端输出显示颜色：git config –global color.ui true

   其中–global参数是指对当前用户所有仓库作用，如果没有–global参数则默认只对当前仓库生效

忽略特殊文件：

1. 忽略特殊文件的作用：有些比如密码文件之类的必须放到工作区，但肯定不能提交到新版本中，因此可以手动指定，让git对某些工作区文件进行忽略

2. 如何忽略特殊文件：在工作区根目录下手动创建一个叫.gitignore的文件，把所有要忽略的文件名写进去即可，只要写名字不需要写目录，而且可以使用通配符例如星号*，可以对某指定规则开头使用取反符号!，注释的语法是井号#。

3. .gitignore文件本身不能忽略：.gitignore文件本身不能忽略，即其本身应该被git管理，因为所有的协作者都应该使用同样的.gitignore文件

4. 哪些文件需要被忽略：

   1. 操作系统自动生成的二级附带文件：缩略图等

   2. 中间文件：如果某个文件会自动生成一些二级文件，那么就没有必要把这些二级文件放进版本库中。常见编译过程产生的文件，例如java编译会产生.class二级文件

   3. 敏感信息：带有敏感信息的文件，例如口令、带密码的配置文件

5. git官方的忽略文件：市面上有很多常见项目比如maven，archlinux什么的，项目又复杂，需要忽略的文件已经被github官方整理好成现成的.gitignore文件在https://github.com/github/gitignore，只需要组合即可

6. windows系统无法在资源管理器下新建一个名字叫.gitignore的文件：未知原因，反正就是提醒让你必须输入文件名，必须通过文本编辑器等其它软件手动通过保存或者另存为之类的方式创建，总之windows自带的资源管理器就是不行

7. 强制add某被忽略文件操作：git add -f 文件名

   使用该命令将会把被忽略的文件add进版本中

8. 检查某文件是否被忽略操作：git check-ignore -v 文件名

   git会定位并返回是.gitignore文件的哪一行的什么规则导致该文件名被忽略

9. 一个项目可以具有多个.gitignore文件：.gitignore文件具有可见域属性，具体而言，其放在哪个目录下，则该目录及其子目录都会受到该.gitignore文件的影响

配置别名：

1. 别名的意义：git大部分都命令都太长了，官方设置了一套命令的别名功能

2. 设定别名：git config –global alias.别名 原名

   例如git config –global alias.st status，意思是，把git status用git st指代

3. 常见别名：

   1. co是checkout的别名

   2. ci是commit的别名

   3. br是branch的别名

搭建Git服务器：

1. 搭建Git服务器的作用：使用git控制版本，但不想用github等托管平台

2. 搭建Git服务器的步骤：因为不需要，就不学了

3. Gitolite：git本身没有对协作者的读写权限控制功能，但git支持钩子hook，可以用其在自己搭建的git服务器上编写一系列脚本来控制协作者的读写权限到具体分支、具体目录，有些公司需要这个功能

使用Source Tree

使用Source Tree：

1. Source Tree是什么：Atlassian开发的免费的图形用户界面Git工具