一、git简介：
Linux创建了Linux，但是Linux的发展壮大是由世界各地的热心志愿者参与编写的？那么那么多份的代码是怎么合并的呢？之前是在2002年以前，世界各地的志愿者把源代码文件通过diff的方式发给Linus，然后由Linus本人通过手工方式合并代码！
你也许会想，为什么Linus不把Linux代码放到版本控制系统里呢？不是有CVS、SVN这些免费的版本控制系统吗？因为Linus坚定地反对CVS和SVN，这些集中式的版本控制系统不但速度慢，而且必须联网才能使用。有一些商用的版本控制系统，虽然比CVS、SVN好用，但那是付费的，和Linux的开源精神不符。
不过，到了2002年，Linux系统已经发展了十年了，代码库之大让Linus很难继续通过手工方式管理了，社区的弟兄们也对这种方式表达了强烈不满，于是Linus选择了一个商业的版本控制系统BitKeeper，BitKeeper的东家BitMover公司出于人道主义精神，授权Linux社区免费使用这个版本控制系统。
安定团结的大好局面在2005年就被打破了，原因是Linux社区牛人聚集，不免沾染了一些梁山好汉的江湖习气。开发Samba的Andrew试图破解BitKeeper的协议（这么干的其实也不只他一个），被BitMover公司发现了（监控工作做得不错！），于是BitMover公司怒了，要收回Linux社区的免费使用权。Linus可以向BitMover公司道个歉，保证以后严格管教弟兄们，嗯，这是不可能的。
实际情况是这样的：Linus花了两周时间自己用C写了一个分布式版本控制系统，这就是Git！一个月之内，Linux系统的源码已经由Git管理了！牛是怎么定义的呢？大家可以体会一下。Git迅速成为最流行的分布式版本控制系统，尤其是2008年，GitHub网站上线了，它为开源项目免费提供Git存储，无数开源项目开始迁移至GitHub，包括jQuery，PHP，Ruby等等。历史就是这么偶然，如果不是当年BitMover公司威胁Linux社区，可能现在我们就没有免费而超级好用的Git了。
二、集中式的版本控制系统和分布式版本控制系统的不同
集中式的版本控制系统： 代表有CVS 、SVN
特点: 版本库集中存放在*服务器 必须联网才能工作 如果*服务器的代码被恶意修改了,所有人的代码都可能会有问题
只能跟踪文本文件的改动，比如txt文件，网页，所有的程序代码等
分布式版本控制系统的是 Git
特点: 版本库在自己的电脑上 不需要联网也能工作 安全性高 只能跟踪文本文件的改动，比如txt文件，网页，所有的程序代码等
强烈建议使用UTF-8编码 所有语言使用同一种编码，既没有冲突，又被所有平台所支持
三、 安装Git
在Linux上安装Git
1. 如果碰到Ubuntu或Debian 请使用下面命令:
$ git //这条命令检查系统中是否有Git
sudo apt-get install git // 如果没有,则使用这条命令来进行安装Git
2. 如果碰到的是 CentOS 请使用下面命令:
$ git // 这条命令检查系统中是否有Git
sudo yum install git
在Windows上安装Git
1. 如果是32位系统 请使用安装包
[32位系统的Git](./Other/Git-2.14.3-32-bit.exe)
2. 如果是64位系统 请使用安装包
[64位系统的Git](./Other/Git-2.14.3-64-bit.exe)
在Mac OS 上安装Git
自己上Git官网搜索 直接下载使用
四、Git安装好了，那么下面我们来一起使用
版本仓库(repository)，那么说是一个文件夹更好理解
> 1. 选择一个合适的地方,创建一个空目录
#打开命令行工具,输入命令 代表新建了一个名字为git的文件夹
mkdir git
# 进入Git文件夹中
cd git
# 查看该文件夹的绝对位置(在windows中) **如果看到输入的pwd中有中文 请确保你的路径中没有中文**
pwd
> 2. 把刚才创建的文件夹目录变成git可以管理的仓库
# 初始化仓库
git init
# 如果你的文件夹中没有任何内容将会得到如下输出结果 代表是初始化了一个空的Git仓库
Initialized empty Git repository in F:/git/.git/
注意： 在使用之前我们来理解一些概念 -----工作区和暂存区---
> 名词解释
1.工作区(Working Directory) ： 就是你在电脑里能看到的目录,比如我的GitHub文件夹目录
2.版本库(Repository)： 在工作区有一个隐藏目录.git,这个就是Git的版本库
3.暂存区： 在版本库中存在一个成为Stage的暂存区,它是专门存储修改和添加的区域。一旦提交后,如果你又没有对工作区做任何修改,那么暂存区就是干净的
## 管理修改(需要案例证明)
为什么Git比其他版本控制系统设计得优秀，因为Git跟踪并管理的是修改，而非文件。你会问，什么是修改？比如你新增了一行，这就是一个修改，删除了一行，也是一个修改，更改了某些字符，也是一个修改，删了一些又加了一些，也是一个修改，甚至创建一个新文件，也算一个修改。
> Git不会提交没有放到暂存区的修改
这里我画了一个图方便大家理解
看了这个图是不是理解了他的工作机制了呢？
下面继续-------------------------------------------------
1 现在我们编写一个first.txt 文件,并把该文件提交修改到git版本库
# 把要提交的文件添加到版本库
git add 文件名
# 把要提交的文件提交到版本库
git commit -m "本次提交的说明"
我们再次对文件进行修改
#查询工作区和版本库的文件状态，红色的代表修改后的文件在工作区，没有添加到暂存区或者提交
#我们来 把刚才的修改后的文件添加和提交一下
> 2. 查看提交的日志记录
# 查看我们提交的历史记录
git log 或 git log --pretty=oneline
git log --pretty=oneline 这个命令让每次提交信息都在一行显示 更清晰直观 前面一串字母和数字代表了每次提交的id号，我们可以根据id 和提交信息找到对应的文件版本，是不是很方便呢
再修改提交几次
next 就是怎么找回以前版本-----惊喜在下面！！！！！
> 3. 版本回退
# 把版本回退到前面的版本 当前版本 HEAD 上一个版本HEAD^ 往上100个版本 HEAD~100
git reset --hard HEAD^
当前版本查询（fourth commit）
上一版本查询（second commit）
......
> 4. 查看自己的每一次命令的记录
# 如果回退到某一个版本之后又后悔了,那么可以再回到某一次提交,这时可以查看自己的写过的命令
git reflog (可以看到全部的提交信息，及版本回退记录)
这时候根据id和提交信息就可以轻松找回你需要的那个版本了
> 5. 回到某一次的提交
# 回到某一次提交就要找到某一次提交的id ,使用fit reflog可以查看自己的命令id
git reset --hard id号（比如找回第四次提交的版本）git reset --hard 第四次提交版本的id号，这样当前版本就是第四次提交的版本啦
## 撤销修改
> 1.当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时
命令： git checkout -- file
> 2.当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改
1. git reset HEAD file
2. git checkout -- file
## 删除文件
> 1.确实要删除
git rm 文件名 把文件删掉
通过git 和 commit 操作的文件 如果在文件夹中 自己手动删除 Git是能跟踪到的
使用 git status
> 2.删错了
git checkout -- files
注意:命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容
现在你可能遇到了两种情况：
1 在git commit 之前 那么就用git checkout -- .\rewrite.txt 撤销
2 如果在git commit之后 那么就用git reset -- hard id 就可以回退到你删除的这个文件版本下
## 创建与合并分支
> 1.查看分支
git branch
> 2.创建分支
git branch 分支名字
> 3.切换分支
git checkout 分支名字
> 4.合并某分支到当前分支
git merge 分支名字（不是当前的分支）
> 5.删除分支
git branch -d 分支名字
## 解决冲突
出现冲突
1 在主分支上有一个文件 confit.txt
2 然后新建一个分支queen
3 切换到新分支
4 在这个新分支上建一个文件 confit.txt
5 更改文件的内容 在新分支上提交
6 切换分支到主分支 ，修改confit.txt（和在新分支上修改同一行）
7 提交
8 合并分支，即出现了冲突
解决方案：商量保留谁提交的内容，然后手动删除被舍弃的内容，最后执行添加并修改
##bug分支
情景：undong.txt 工作还没做完（暂存区有很多add文件，这时还没有commit），这时接收到一个必须在两小时内完成的bug文件（和之前的工作无关）
1 这时就要保存工作现场 git stash
2 添加新分支 git branch fixbug
3 切换到这个分支 git checkout fixbug
4 git add bug文件
5 提交 git commit
6 删除该分支（一般情况应该合并）
查看分支现场 git
7 修复之前的分支 git stash pop