写在前面

Git作为目前世界上最先进的分布式版本控制系统，可以算是程序员必备技能了。

一直都知道学会它的重要性，但就是没有花时间好好学习一下。这两天借跑实验数据的时间，打算好好学习一下，认真静下心来，没有什么问题是真的学不会的吧。

发现自己最近心理素质真是蹭蹭蹭的开始往上涨了哈哈哈～～～

(一) Git 基本入门

1. 安装Git

在linux下安装Git很简单，只需要输入以下语句就可以了：sudo apt-get install git
初始配置: 作为分布式版本控制系统，每个机器都必须自报家门，Git需要知道我们的用户名和email，需在在命令行进行如下配置。
```
git config --global user.name "YourName"
git config --global user.email "[email protected]"
```

2. 创建版本库

进入到自己想创建版本库的目录
输入指令： git init

如图所示，会在目录中创建.git的目录，这个目录就是Git用来跟踪管理版本库的。

3. 文件添加进版本库

git add filename 将文件名为filename的文件添加进仓库，可以多个文件名并列，用空格隔开。
git add --all 命令将当前所有文件添加进仓库；
注: 这里git add只是相当于选中的功能，还没有放进去。
git commit -m "describe it" 命令执行将文件提交到仓库的操作，这个时候才放进去了。
要使用Git进行管理的文件一定要在当前目录下，即与.git文件夹处于同级，否则Git找不到它。

4. 查看仓库状态: git status

git status 可以随时仓库当前状态，查看已经命令过但还未经提交到仓库的所有操作，可以看成是待处理事项列表。
原来的我们加入的文件1.txt是空的，什么内容都没有，现在尝试输入一点内容。

如图所示，git可以检测到我们对文件做了改动，但还没有准备提交的命令下达。

5. 查看更改内容：git diff

git status命令我们只知道做了修改，但是还不知道具体修改的内容
git diff这个命令就帮助我们解决这个问题。

现在就可以知道我在文档里加入的是什么内容了。

6. 更新文件

文件如果修改过，提交修改和提交新文件是一样的。

git add 1.txt
git commit -m "modify 1.txt"

7. 查看操作记录：git log

git log 会打印我们对仓库所作的操作记录
git log --pretty oneline 单行打印历史操作记录
输出的一大串数字属于 commit id

8. 查看历史命令: git reflog

记录了每一次命令
可以在版本回退时用来恢复到未来的状态查找版本号

(二) Git 版本管理入门

1. 版本回退: git reset

每一次commit都是对应一个版本
commit id是对版本的具体标识
HEAD表示当前版本
HEAD^表示上一个版本
HEAD^^表示上上版本
HEAD~100表示前100个版本
git reset --hard commitId 回退到版本号为commitId的地方，也可以用HEAD的形式表示。
穿梭前，用git log查看提交历史，以便确定要回退到哪个版本。
重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。

2. 工作区和暂存区

先上一张很经典的图
工作区：就是我们在电脑中实际看到的；
版本库：工作区中的隐藏目录.git，就是版本库；
暂存区：暂存区的概念很重要，理解暂存区之后对于Git的版本管理会有一个比较清晰的思路。
master: 这是Git为我们自动创建的第一个分支。
我觉得如果把工作区看成是键盘终端输入，版本库中的master可以看成是电脑硬盘，我们输入的内容首先是到缓存中的，并不是直接存入硬盘。当缓存区满或者人为发送指令时才会将缓存区的内容写入硬盘。
以添加和文件修改为例，git add指令只是选中文件或者其他要提交的修改，将它们添加进暂存区。只有使用git commit指令的时候，才将暂存区的所有内容提交到当前分支。

3. 撤销修改

工作区文件内容被修改，但还没有添加到暂存区：那么直接丢弃工作区的修改，回到跟版本库一样的状态。
git checkout -- file
工作区文件内容被修改，并且已经添加进暂存区，但还没有commit：如果这时候直接用上面那条语句，那么工作区的文件会恢复到跟上一次提交到暂存区的一样。所以要先将暂存区的修改撤除，这样就跟上面的情况一样，然后再丢弃工作区的修改。
```
git reset HEAD file
git checkout -- file
```
工作区文件内容被修改，且已经提交： 用版本回退git reset的方法进行恢复。

4. 删除文件

前提：一个文件已经提交到版本库后手动删除或者rm file指令删除
git status可以看到文件被删除。
确定删除：那就需要从版本库中也删除文件：
```
git rm file
git commit -m "remove file"
```
恢复文件：删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：
```
git checkout -- test.txt
```
git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。
（持续更新中～～～～）

(三) Git 远程仓库

之前学习的都是本地仓库的管理，但是如果有一个远程仓库既可以用来存放又可以在本地仓库跟远程仓库之间进行同步就太好了。

Github就属于远程仓库。之前一直觉得Github很难学，现在对Git有了一定的了解之后，至少觉得它不是那么遥不可及的了。

1. Github和Bitbucket的简单介绍

这两个都是用的比较多的远程仓库管理平台，在学习了一些资料之后做一点归纳性的总结工作：

两者都可以为你的代码托管提供帮助；
两者都可以使用Git进行管理；
Github更关注开源，你需要为私有项目付费；
Bitbucket提供无限的免费私人仓库，还支持五人团队开发；
相对来说，GitHub上面的项目资源或更多一些，功能也会强大很多；

总的来说，建议同时使用GitHub和BItbucket，私人或者暂不适合公开的项目就选择用Bitbucket管理，公开项目就放到Github上面。

2. 添加远程仓库并关联

在Github或者BItbucket中创建好一个仓库repository后，可以把本地已经有的仓库与之关联。然后把本地的内容推动到远程仓库。
关联远程库，使用命令：
git remote add origin git@server-name:path/repo-name.git
关联后，使用该命令执行第一次推送master分支的所有内容：
git push -u origin master
以后每次本地仓库提交之后，想要将修改同步到远程仓库，都可以使用以下命令：
git push origin master

3. 从远程仓库克隆

上面我们讲的是现有本地仓库，然后创建远程仓库来同步它的情况。最好的方式是一开始就先创建好远程库，然后从远程库克隆到本地。

最简单的方式是直接点击远程仓库上的‘clone`进行克隆。
代码方式：生成远程仓库后都会有一个仓库地址，使用git clone命令进行克隆即可。常见形式为：
git clone git@server-name:path/repo-name.git

(四) 分支管理

1. 分支需求描述

不完整的改动可以先放到分支上，这样别人看不到分支的内容，不会相互影响。可以直到开发完毕后，再一次性合并到原来的分支上.
一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

只有一条master时间线

2. 创建、合并和删除分支

2.1 原理

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

创建新的分支dev
Git创建一个分支很快，增加一个dev指针，改改HEAD的指向. 从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

对工作区的修改和提交
合并分支:把dev合并到master上, 最简单的方法就是直接把master指向dev的当前提交，就完成了合并：

合并分支
删除分支:删除dev分支就是把dev指针给删掉，删掉后就剩下了一条master分支：

删除分支

2.2 实战

take dev as an example
创建分支: git branch dev
切换到分支:git checkout dev
创建+切换分支: git checkout -b dev
查看当前分支:git branch
切换到master分支:git checkout master
合并指定分支到当前分支:git merge dev
删除分支:git branch -d dev
git log --graph命令可以看到分支合并图。

3. 分支策略

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

master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
4.所以，团队合作的分支看起来就像这样：

团队合作分支

4. Bug分支

修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当工作没有完成时，先把工作现场git stash一下，然后去修复bug.
修复后，再git stash pop，回到工作现场。
要丢弃一个没有被合并过的分支，可以通过git branch -D 强行删除。

5. 多人协作

5.1 基本命令

当从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。
要查看远程库的信息，用git remote
显示更详细的信息, 用git remote -v
推送分支: 就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：
```
git push origin master  
git push origin dev
```
并不是一定要把本地分支往远程推送,master分支是主分支，因此要时刻与远程同步, 其他视情况而定.
git pull 抓取远程的新提交.
在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；
建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；

5.2 工作模式总结

首先，用git push origin branch-name推送自己的修改；
如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
如果合并有冲突，则解决冲突，并在本地提交；
没有冲突或者解决掉冲突后，再用git push origin branch-name推送就能成功！
如果git pull提示“no tracking information”，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream branch-name origin/branch-name。

最后

真的是超级感谢廖雪峰老师提供的Git教程了，大赞(≧▽≦)/

文章很多图和文章都从这里摘录，教程讲的真的蛮容易理解学习的，推荐给同样想学的人哦(๑•ั็ω•็ั๑)

参考文献

Git教程
怎么样使用github
GitHub vs. Bitbucket 不只是功能不同

科研工具 | 分布式版本控制：Git学习笔记