该文章有部分参考某大神的文章，具体也忘了出处了，如果有发现跟哪个文章类似，麻烦留言下，我好注明出处。 当然的看清楚对方文章的发表时间必须早于2017年10月。

Git 是什么

目前最先进的分布式 版本控制系统。

为什么要版本控制系统

如果你正在写一份报告，你可能需要修改N多次，每一次的修改你都担心可能后面会改回原样，但又担心忘了自己修改的点，这时你就不得不每修改一次，保存一次报告，这样你可能一份报告会有非常多份的备份文件。 时间长了，你真想回看某个修改点原来样子，你又忘了是哪个备份时做了这个修改，你又不得不一个一个文件打开跟现在文件对比，这些找，对比，备份都是非常麻烦的事情。 那么版本控制系统就可以轻松替你解决这些头痛点。

分布式和集中式的区别

集中式

SVN CVS都属于集中式的版本控制系统。集中式版本控制系统，版本库是集中存放在中央服务器的，而干活的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。中央服务器就好比是一个图书馆，你要改一本书，必须先从图书馆借出来，然后回到家自己改，改完了，再放回图书馆。

集中式版本控制系统看起来解决我们要的版本管理最大毛病，必须联网才能工作，局域网内带宽够大，才避免提交或者check out 一个文件等待时间非常长问题

分布式

分布式版本控制系统没有“中央服务器”的概念，每个人的电脑都是一份完整的版本库，这样工作时可以不需要联网，因为版本库就这自己电脑上。 那么如果多人协作呢？比方你修改了本地电脑A，你同事也在他本地修改了A文件，这是你们俩之间只需要把各自的修改推送给对方，就可以互相看到对方的修改了。比起集中式分布式版本控制系统更加安全，每个人本地都有一份完整的版本库，不担心集中式的中央服务器出问题了，而所有人都没法工作。

Git基本概念

三种状态

Git 有三种状态，你的文件可能处
于其中之一：已提交（committed）、已修改（modified）和已暂存（staged）
。已提交表示数据已经安全的
保存在本地数据库中。已修改表示修改了文件，但还没保存到数据库中。已暂存表示对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中。

三个工作区

由此引入 Git 项目的三个工作区域的概念：Git 仓库、工作目录以及暂存区域。

Git 仓库目录是 Git 用来保存项目的元数据和对象数据库的地方。这是 Git 中最重要的部分，从其它计算机克隆
仓库时，拷贝的就是这里的数据。
工作目录是对项目的某个版本独立提取出来的内容。这些从 Git 仓库的压缩数据库中提取出来的文件，放在磁盘
上供你使用或修改。
暂存区域是一个文件，保存了下次将提交的文件列表信息，一般在 Git 仓库目录中。有时候也被称作`‘索
引’’，不过一般说法还是叫暂存区域。

Git 基本工作流程：

1. 在工作目录中修改文件。
2. 暂存文件，将文件的快照放入暂存区域。
3. 提交更新，找到暂存区域的文件，将快照永久性存储到 Git 仓库目录。

Git 安装

Win 版本

下载地址：https://git-scm.com/download/win

Git GUI客户端（可选）

https://git-scm.com/download/gui/windows 推荐用SourceTree

Git 常用命令介绍

查看默认全局配置

$ git config --list

修改/添加用户信息

当安装完 Git 应该做的第一件事就是设置你的用户名称与邮件地址。这么做很重要，因为每一个 Git 的提交都会使用这些信息，并且它会写入到你的每一次提交：

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

设置完后我们可以再次用 git config —list 查看详细配置。

获取帮助

$ git help config

初始化仓库

$ mkdir gitDemo  // 创建gitDemo 文件夹
$ git init  // 初始化git仓库

创建文件，并添加到暂存区

$ touch readme.txt  // 创建 readme.txt 文件
$ git add readme.txt  // 添加文件到暂存区

提交到本地仓库

$ git commit -m "这个是提交说明"   // 提交文件到本地仓库

查看状态

$ git status  // 详细状态
$ git status -s  // 简短状态

对比

要查看尚未暂存的文件更新了哪些部分：

$ git diff

查看已暂存的将要添加到下次提交里的内容：

$ git diff --staged

查看提交历史

查看提交历史

按提交时间，列出所有更新：

$ git log

查看每次提交的内容差异

查看最新3次提交的具体情况：

$ git log -p -3

查看每次提交的简短统计信息

$ git log --stat

版本回退

回到当前分支的上一个版本：

$ git reset --hard HEAD^

回退到当前分支的上上个版本：

$ git reset --hard HEAD^^

回退到当前分支的前100个版本：

$ git reset --hard HEAD~100

通过以下方式回退到某个详细版本，先通过git log/reflog拿到需要回退版本的一个hash值的头部，比如通过git log获取到3628164…，回退到3628164…版本：

$ git reset --hard 3628164

删除文件

删除工作区的文件

$ rm test.txt

删除版本库文件

$ git rm test.txt

另外一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本, git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”：

$ git checkout -- test.txt

添加到远程仓库

1. 第一次使用要先链接到远程仓
   通常使用origin作为默认名，后面跟上你远程仓库地址
   $ git remote add origin https://github.com/MeYoungTester/GitTest.git
2. 提交到远程仓
   用origin 账号提交到master分支
   $ git push -u origin master

如果第一次提交通常还会让你输入远程仓访问的账号密码：

从远程仓克隆

$ git clone https://github.com/MeYoungTester/GitTest.git

更新远程仓代码到本地

$ git pull

分支管理

创建分支

$ git branch dev
$ git checkout dev

上面两行命令创建创建一个dev分支，并切换，相当于下面一个命令：

$ git checkout -b dev

创建一个dev分支, git checkout命令加上-b参数表⽰示创建并切换。
如果这时想切换会master分支：

$ git checkout master

切换回主分支后，我们可以把dev分支合并过来：

$ git merge dev

合并后如果想删除dev分支：

$ git branch -d qa

命令汇总:

• 查看分支：git branch
• 创建分支：git branch name
• 切换分支：git checkout name
• 创建+切换分支：git checkout -b name
• 合并某分支到当前分⽀支：git merge name
• 删除分支：git branch -d name

解决冲突

建议直接上GUI工具，例如IDEA，后面讲IDEA演示时讲解。

分支策略

详细方案可以参考：http://blog.jobbole.com/109466/

简单来个例子：

master分支应该是非常稳定的分支, 主要用来发布, 平时绝对不能在上边干活
dev分支是不稳定的分支, 可以在上边做开发, 然后待稳定了,合并到master去
然后可以考虑每个功能团队拉一个分支,进行自己的研发, 如下图:

bug 临时分支：

当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue -101来修复它，但是，等等，当前正在dev上进行的工作还没有提交(没有git add), 不是我不想提交, 而是这个功能需要12个小时才能完成, 这会儿提交上去连编译都过不了, 会block 项目的daily build. 这时候怎么办?
git stash 使用这个命令把现场保留并”存储”下来, 等bug解决了以后再恢复现场重新写码.
在使用了git stash保留了现场之后,使用git status来查看工作区, 就是干净的. 此时可以使用命令 git checkout -b issue_101 拉一个issue_101临时分支来解决bug, 然后再合并到master去
合并之后使用命令 git checkout dev 切换回dev分支,继续刚才的工作
但是使用git status,发现工作区是干净的, 怎么回到刚才的工作现场?
使用 git stash list 来查看有多少个现场被保留了
然后使用git stash pop 来回到最近的一个现场, 如果现场很多, 可以使用以下命令恢复:
git stash apply stash@{0}

feature 分支

现在接到了一个新任务：开发代号为Vulcan的新功能, 于是先建一个branch: git checkout -b feature-Vulcan 然后花了一些时间完成了vulcan.java 你就使用add和commit提交到了这个vulcan的branch上
但是主管告诉你说,这个功能突然被砍掉了,不做了
虽然白干了,但是还是要把这个分支删除, 然后使用命令:
git branch -d feature-Vulcan 发现删除不掉
原因是feature-vulcan分支还没有被合并,如果删除,会丢失修改, 只能用-D删除, 于是使用命令:
git branch -D feature-Vulcan 删除成功
Tips:
每个新功能建议都开个新分支, 如果要丢弃新分支, git branch -D可以使用

标签管理（tag）

发布一个版本时，我们通常先在版本库中打一个标签(tag)，这样，就唯一确定了打标签时刻的版
本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照
使用命令git tag v1.0就可以打上一个标签
可以用命令git tag查看所有标签
默认情况下使用git tag 是给最近的一次commit打上标签,但是如果需要给之前的commit打上标要怎么办呢?
方法是找到历史提交的commit, 然后打上就好了.
git log —pretty=oneline —abbrev-commit 找到某个commit 历史, 例如找到 fix bug 101这个commit, 而这个commit的id是12345678,那么通过命令:
git tag v0.9 12345678 就给这个fix bug 101的commit打上了v0.9的tag
如果你想要查看v0.9这个tag的信息,可以使用命令 git show v0.9 查看
在打标签的时候, 你当然希望可以自己指定版本号和说明,那么就使用-a和-m参数: git tag -a v0.1 -m “version 0.1 released” 3628164

gitignore文件配置参考地址：

https://github.com/github/gitignore