Git入门
安装
linux环境安装
查看git有没有安装，直接输入命令
git
如果未安装，会提示安装命令，根据提示安装即可
#### mac环境安装
1）先安装homebrew
在命令行输入以下命令
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
2）使用homebrew安装git
brew install git
### 使用
基本命令
1）创建版本库
使用如下命令创建版本库
# 将当前目录作为一个git仓库
git init
2）查看当前版本库状态
git status
3）添加文件到暂存区
# 添加单个文件
git add 1.txt
# 添加多个文件
git add 1.txt 2.txt
# 提交新文件(new)和被修改(modified)文件，不包括被删除(deleted)文件
git add .
# 提交被修改(modified)和被删除(deleted)文件，不包括新文件(new)
git add -U
# 添加所有修改（上两个功能的集合）
git add -A
4）比较当前工作区、暂存区、分支之间的差异
# 查看当前工作区与暂存区的差异，也就是修改了还没有add的部分（不包括新建文件）
git diff
# 查看暂存区与分支之间的差异，也就是add了还没有commit的部分
git diff --cached
5）撤销修改
撤销修改有两种情况：
一是这个文件自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；
二是已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。
总之，就是让这个文件回到最近一次git commit或git add时的状态。
git checkout -- 1.txt
如果已经add到暂存区但是还没有提交，想要回退怎么办呢，可以使用如下命令
# 把暂存区的修改撤销掉（unstage），重新放回工作区
git reset HEAD 1.txt
注意：git reset既可以回退版本，也可以把暂存区的修改回退到工作区，当我们用HEAD时，表示最新的版本。
然后再使用git checkout丢弃工作区的修改就可以了
4）提交
# 格式：git commit -m <message>，不加message会跳转到vim界面
git commit -m "create 1.txt"
5）查看提交的版本记录（注意版本回退后看不到回退版本号之后记录）
git log
# 让结果一行显示
git log --pretty=oneline
6）版本回退
# 回退到上一个版本（HEAD表示当前版本）
git reset --hard HEAD^
# 回退到上两个版本
git reset --hard HEAD^^
# 回退到上五个版本
git reset ---hard HEAD~5
7）查看使用git 命令进行操作的日志（可以查看所有的版本记录）
git reflog
8）删除文件
加入你删除了一个文件
rm 1.txt
如果你确实要删除这个文件，使用`git rm`就行
git rm 1.txt
git commit -m "remove 1.txt"
如果删错了，想要恢复，也容易，因为版本库还有，可以很轻松地把误删文件恢复到最新版本
git checkout -- 1.txt
git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。
#### 几个概念
1）工作区（Working Directory）
工作区就是所在目录
2）版本库（Repository）
工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。
Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
分支管理
创建和合并分支
每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支，git默认有一个master分支，称为主分支
一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点
每次提交，`master`分支都会向前移动一步，这样，随着你不断提交，`master`分支的线也越来越长。
当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：
不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：
假如我们在`dev`上的工作完成了，就可以把`dev`合并到`master`上。Git怎么合并呢？最简单的方法，就是直接把`master`指向`dev`的当前提交，就完成了合并：
合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：
1）创建分支
# 创建分支
git branch dev
# 切换到dev分支
# 创建并切换到dev分支（上述两条命令合一）
git checkout -b dev
2）查看分支
git branch
3）合并分支
# 切换到master分支
git checkout master
# 将dev分支合并到当前分支
git merge dev
git merge命令用与合并指定分支到当前分支，注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。
4）删除分支
合并之后就可以删除dev分支了，命令为
git branch -d dev
因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在`master`分支上工作效果是一样的，但过程更安全。
注意：如果在一个分支上修改了但没有commit，那么切换到其他的分支后还是能看到之前分支做的修改，因为工作区和暂存区对所有分支来说是公共的
##### 解决冲突
加入我们两个分支上都分别做了修改，这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，提示
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.
使用`git status`来查看冲突文件
打开冲突文件，可以看到git用<<<<<<<<, =========, >>>>>>>>标记出不同分支的内容，我们可以手动修改后保存再提交，现在，master分支和feature1分支变成了下图所示：
使用带参数的git log可以看到分支的合并情况
git log --graph --pretty=oneline --abbrev-commit
通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
# 切换到master分支
git checkout master
# --no-ff表示禁用fast forward模式合并
git merge --no-ff -m "merger with no-ff" dev
注意使用`--no-ff`模式会提交一个新的commit，所以要加上-m "message"
不使用fast forward模式，merge后如下图
##### 分支管理策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：
