声明：这篇文章来源于廖雪峰老师的官方网站，我仅仅是作为学习之用
Git简介
Git是什么？
Git是目前世界上最先进的分布式版本控制系统。
什么是版本控制系统？
Git的诞生
很多人知道，Linus在1991年开源了Linux，从此，Linux系统不断发展，已经成为最大的服务器系统软件了。
Linus虽然创建了Linux，但Linux的壮大是靠全世界热心的志愿者参与的，这么多人在世界各地为Linux编写代码，那么Linux的代码是如何管理的呢？
事实上，在2002年以前，代码作者把源文件以diff的方式发给Linus，然后由Linus本人通过手工的方式合并代码。
当时也有免费的CVS、SVN这些免费的版本控制系统。但是Linus坚决的反对CVS、SVN，这些集中式的版本控制系统不但速度慢，而且必须联网才能使用。
不过到了2002年，经过十年的发展，通过手工方式管理代码已经相当累人啦，而且社区的兄弟们也对这种方式表达了强烈的不满，于是Linus选择了一个商业的版本控制系统BitKeeper。BitKeeper的东家BitMover公司出于人道精神，授权Linux社区免费使用这个版本控制系统。
安定团结的局面在2005年被打破了，原因是开发Samba的Andrew试图破解BitKeeper的协议，被BitMover公司发现了，要收回Linux社区的免费使用权。
于是Linus花了两周的时间自己用C写了一个分布式的版本控制系统，这就是Git！一个月之内，Linux系统的源码就可以由Git管理了！
Git迅速成为最流行的分布式版本控制系统，尤其是2008年，GitHub网站上线了，它为开源项目提供免费Git存储，无数开源项目开始迁移至GitHub，包括JQuery，PHP，Ruby等等。
历史就是这么偶然，如果不是当年BitMover的决绝，那么现在我们可能就没有免费而且超级好用的Git了。
集中式VS分布式
Linus一直痛恨的CVS和SVN都是集中式的版本控制系统，而Git是分布式的版本控制系统，集中式和分布式的版本控制系统有什么分别呢？
先说集中式版本控制系统，版本库是放在中央服务器上的，而干活的时候，用的都是自己的电脑，就需要把版本先从中央服务器取得最新的版本，然后开始干活。干完活了，再把自己的劳动成果推给中央服务器。
集中式版本控制系统最大的问题就是必须联网才能工作。如果在局域网内还好说，带宽够大，速度够大。可如果在互联网上，遭遇网速慢的情况，可能提交一个10M的文件就需要5分钟。5分钟可以憋死一头牛啦。
分布式版本控制系统呢？它没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样你干活的时候就不需要联网啦，因为版本库就在本地啊。既然每个人的电脑上都有一个版本库，那么如何多人协作呢？比方说你在自己的电脑上修改了A文件，你的同事也在他的电脑上修改了A文件；你们只需要把修改的地方推给对方就可以互相看到对方的修改了。
和集中式版本控制系统相比，分布式版本控制系统的安全性不知道要高到哪里去。因为每个人电脑里都有完整的版本库，某个人的电脑坏了也不要紧，随便从其他人那里复制一个就可以。而集中式版本控制器的中央服务器要是出了问题，所有人都没法干活了。
在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改，因为可能你们俩不在同一个局域网内，两台电脑互相访问不了；也可能你的同事今天生了病，根本就没开机。因此，分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改；没有它大家一样干活，只是交换修改不方便了而已。
当然Git优势不单是不必联网这么简单，后面我们还会看到Git极其强大的分支管理，把SVN等远远抛在了后面。
安装Git
在Linux上安装Git
如果你碰巧使用Debian或Ubuntu Linux，通过一条 sudo apt-get install git 就可以完成git的安装，非常之简单。
如果是其它Linux的版本，可以直接通过源码安装。先从Git官网下载源码，然后解压，依次输入: ./config, make, sudo make install 这几个命令就安装好了。
在Mac上安装Git
推荐一种简单的方法。直接从AppStore安装Xcode，Xcode中集成了Git，不过默认没有安装。你需要运行Xcode，选择菜单"Xcode"->"Preferences"，在弹出的窗口中找到“Downloads”，选择“Command Line Tools”，点“Install”就可以完成安装啦。
安装完成后，还需要进行最后一步设置，在命令行输入：
$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"
因为Git是分布式版本控制系统，所以每个机器都必须自报家门。
注意git config命令的--global参数。用了这个参数，表示你的这台机器上所有的Git仓库都会使用这个配置。当然你也可以对某个仓库指定不同的用户名和email地址。
创建版本库
版本库又叫仓库，英文名repository。版本库可以简单的理解成目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能追踪，以便在任何时刻都可以追踪历史，或者在将来的某个时候可以“还原”。
创建版本库非常简单，选择一个合适的地方，创建一个空目录：
$ mkdir learngit
$ cd learngit
$ pwd
/Users/michael/learngit
pwd命令用于显示当前目录。在我的Mac上，这个仓库位于/Users/michael/learngit。
第二步，通过git init命令把这个目录变成Git可以管理的仓库：
$ git init
Initialized empty Git repository in /Users/michael/learngit/.git
瞬间Git仓库就建好了，而且告诉你是一个空仓库，多出来的 .git目录是来跟踪管理版本库的，里面的文件不能手动修改，否则Git仓库会遭到破坏。
如果没有看到.git目录，那是因为这个目录默认是隐藏的，用ls -ah命令就可以看见。
把文件添加到版本库
首先声明一点，所有的版本控制系统，其实只能跟踪文本文件的改变，比如txt文件，网页，所有的程序代码等等。Git也不例外。版本控制系统可以告诉你每次的改动，比如第5行增加了一个单词“Linux”，而在第8行删除了一个单词“Windows”等等...。而图片、视频这些二进制文件虽然也能由版本控制系统管理，但没法跟踪文件的改变，只能把二进制文件每次改动串起来，也就是只知道图片从100KB改成了120KB，但是到底改了啥，版本控制系统不知道，也没法知道。
不幸的是Microsoft的Word格式是二进制格式，因此版本控制系统无法跟踪Word的改变。如果要真正实用版本控制系统，就要以纯文本的方式编写文件。因为文本是有编码的，如中文有常用的GBK编码，日文有常用的Shift_JIS编码，如果没有历史遗留问题，强烈推荐使用标准的UTF-8编码，所有的语言使用同一种编码，既没有冲突，又被所有平台所支持。
另外注意千万不要用windows自带的记事本 编辑任何文本文件。原因是记事本保存UTF-8编码文件时会在每个文件开头添加0xefbbbf字符。
言归正传，现在编写一个readme.txt文件，内容如下：
Git is a version control system.
Git is free software.
这个文件一定要放在learngit目录下，放在别的地方Git找不到。
把一个文件放到Git仓库只需要两步：
第一步， 用git add告诉git，把文件添加到仓库
$ git add readme.txt
第二步，用git commit告诉Git，把文件提交到仓库
$ git commit -m "wrote a readme file"
[master (root -commit) cb926e7] wrote a readme file 1 file changed, 2 insertions(+)
create mode 10064 readme.txt
简单解释一下git commit命令，-m后面输入的是本次提交的说明，这样你就能从历史纪录中方便的查找改动纪录。
时光穿梭机
我们已经添加并提交了一个readme.txt文件，现在我们修改readme.txt，改成如下内容：
Git is a distributed version control system.
Git is free software.
现在运行git status 命令。git status命令可以让我们看到仓库的状态，上面的命令告诉我们，readme.txt被修改过了。并且告诉我们后序的处理方案。git add将修改添加到仓库，git checkout丢弃修改。
git status只能告诉我们修改了哪些文件，但具体修改了文件的哪些内容就需要用git diff这个命令了。
提交修改
提交修改和提交新文件是一样的两个步骤。
第一步 是git add
$ git add readme.txt
在执行第二步git commit之前，我们用git status查看仓库状态。git commit命令告诉我们后序的操作，看来Git还是很友好的。
$ git commit -m "add distributed"
提交后，我们再用git status命令查看仓库状态。
$ git status
# On branch master
nothing to commit (working directory clean)
Git 告诉我们当前没有需要提交的修改，工作目录是干净的。
小结
- 随时掌握工作区状态，使用
git status命令 - 用
git diff可以查看具体的修改内容
版本回退
现在我们再次修改readme.txt文件
Git is a distributed version control system.
Git is free software distributed under the GPL.
然后提交
$ git add readme.txt
$ git commit -m "append GPL"
像这样可以不断修改不断提交到版本库，这样Git就能跟踪文本的改变。当你觉得文件修改到一定程度的时候，就可以“保存一个快照”，这个快找在Git中成为commit。一旦你把文件改乱了，或者误删了文件，就可以从最近的一个commit恢复，然后继续工作。这样就不会把前几个月的工作成果丢失。
现在我们的Git仓库中有三个版本啦。
版本1: wrote a readme file
版本2: add distributed
版本3: append GPL
查看历史纪录
版本控制系统有某个命令可以查看历史纪录，在Git中git log就是也。
$ git log
commit 8ae8b878c335c5ae8ed381460345d2b03e8e3c6e
Author: zhangxiaojun <adam.zhang@ydx.hk>
Date: Fri Mar 11 00:01:24 2016 +0800
append GPL
commit 3eb82b8e2c94fbc5fdb0ca248fa7c15789df922c
Author: zhangxiaojun <adam.zhang@ydx.hk>
Date: Thu Mar 10 23:59:53 2016 +0800
add distributed
commit e9da25c20a570b2f6280d3bb47a5e0d3935a5a8b
Author: zhangxiaojun <adam.zhang@ydx.hk>
Date: Thu Mar 10 23:58:00 2016 +0800
wrote a readme file
git log可以显示从最近到最远的提交日至。如果嫌弃输出太多的信息，可以加上--pretty=oneline参数：
$ git log --pretty=oneline
8ae8b878c335c5ae8ed381460345d2b03e8e3c6e append GPL
3eb82b8e2c94fbc5fdb0ca248fa7c15789df922c add distributed
e9da25c20a570b2f6280d3bb47a5e0d3935a5a8b wrote a readme file
版本号
一大串类似8ae8b87...d2b03ec6e的数字是commit id（版本号）。和SVN不一样，Git的commit id不是1、2、3...的递增数字，而是由SHA1计算出来的一个非常大的数字，用十六进制表示。为什么commit id需要一串这么大的数字来表示呢？因为Git是分布式控制系统，后面我们还要研究多个人在同一个版本库工作，如果大家都用1、2、3...作为版本号，那么肯定会引发冲突。
每提交一个版本，实际Git就会把它们自动串成一条时间线。如果使用可视化工具查看Git历史，就可以清楚地看到提交历史的时间线。
时光穿梭机
首先Git必须要知道当前版本是哪个版本，在Git中用HEAD表示当前版本，也就是最新的commit id，上一个版本用HEAD^表示，上上个版本是HEAD^^,再往上一个版本就是HEARD~3。
现在我们从当前版本“append GPL”退回到上一个版本“add distributed”，就可以使用git reset命令：
$ git reset --hard HEAD^
HEAD is now at 3eb82b8 add distributed
最新版本"append GPL"已经不见了！好比从21世纪坐时光穿梭机回到了19世纪，现在又想回去了，肿么办？
办法还是有的，只要刚才的命令行窗口没有关，可以往上找到"append GPL"对应的commit id,于是就可以回到未来的某个版本
$ git reset --hard 8ae8
HEAD is now at 8ae8b87 append GPL
Git的版本回退速度是非常快，因为Git在内部有个指向当前版本的HEAD指针，当你回退版本时，Git仅仅是把HEAD指向append GPL。然后顺便把工作区的文件更新了，所以你让HEAD指向哪个版本号，你就把当前版本定位在了哪里。
现在你回退到了某个版本，关掉了电脑，第二天早上就后悔了，想要恢复到最新的版本怎么办？找不到新版本的commit id怎么办？
在Git中总是有后悔药可医吃的。Git提供了一个命令git reflog来纪录你的每一次命令：
$ git reflog
e9da25c HEAD@{0}: reset: moving to HEAD^^
8ae8b87 HEAD@{1}: reset: moving to 8ae8
3eb82b8 HEAD@{2}: reset: moving to HEAD^
8ae8b87 HEAD@{3}: commit: append GPL
3eb82b8 HEAD@{4}: commit: add distributed
e9da25c HEAD@{5}: commit (initial): wrote a readme file
长出一口气，第5行显示 append GPL的commit id是 8ae8b87。现在我们可以乘坐时光机回到未来了。
小结
小结一下
-
HEAD指向的版本就是当前版本，Git允许我们在版本之间时光穿梭，使用命令git reset --hard commit_id。 - 穿梭前，用
git log查看提交历史纪录，以便确认要退到哪个版本。 - 要重返未来，用
git reflog查看命令历史，以便确定回到未来的哪个版本。
远程仓库
用过集中式版本管理系统的同学会说，前面这些功能SVN里早就有了，没有看出Git有什么特别的地方。
没错，如果只是一个仓库管理文件历史，Git和SVN真的没啥区别。为了保证你学习Git物超所值，将来绝对不会后悔，我们开始介绍Git的杀手级功能之一：远程仓库。
Git是分布式版本控制系统，同一个Git仓库，可以分布到不同的机器上。怎么分布呢？最早，肯定只有一台机器有一个原始版本，此后，别的机器可以“克隆”这个原始版本库，而且每台机器的版本库其实都是一样的，并没有主次之分。
你肯定会想，至少需要两台机器才能玩远程库不是？但是直有一台电脑怎么玩？
- 其实一台电脑也可以玩，只要仓库在不同的目录下，但是在世纪开发中这种方式完全没有意思。
- 实际开发时，需要自己搭建一台运行Git的服务器。
- 有一个叫GitHub的神奇网站，这个网站是专门提供Git仓库托管服务的，所以，只要注册一个GitHub账号，就可以免费获得Git远程仓库。
我们现在就将Git仓库托管到GitHub上，来看一下具体的步骤。
第一步，创建 SSH KEY。在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果有了可以直接进行下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH KEY：
$ ssh-keygen -t rsa -C "youremail@example.com"
需要把邮件地址换成自己的邮件地址，然后一路回车，使用默认值即可，也无需设置密码。
如果一切顺利会在用户主目录找到.ssh目录里面有id_rsa和id_rsa.pub这两个文件。这两个就是SSH的秘钥对，id_rsa是私钥，id_rsa.pub是公钥，公钥可以放心的告诉别人。
第二步，登录GitHub，打开“Account settings”，“SSH Keys”页面。然后点击“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件内容，通俗的讲就是把公钥告诉GitHub。
为什么GitHub需要知道你的SSH Key呢？因为GitHub需要认证你推送的提交确实是你推送的，而不是别人冒充的。而Git支持SSH协议，所以GitHub只要知道了你的公钥，就可以确定只有你自己才能推送。
当然GitHub允许你添加多个key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交。只要把每台电脑的key都添加到GitHub，就可以在每台电脑上往GitHub推送了。
最后友情提示，在GitHub上免费托管的Git仓库，任何人都可以看到喔（但是只有你自己才能修改）。所以不要把敏感信息放进去。
如果你不想让别人看到Git仓库，有两个办法。一个是交点保护费把公开的仓库变成私有的，这样别人就看不到了。另一个办法是自己动手搭建一个Git服务器。
小结
有了Git远程仓库，再也不用担心自己的硬盘了，代码的存放也会有管家替我管理啦，另外我也可以把纯文本的学习笔记让GitHub替我托管啦。
添加远程仓库
现在的情景是，你已经在本地创建了一个Git仓库后，又想在GitHub创建一个Git仓库，并且让这两个仓库进行远程同步，这样GitHub上的仓库即可以作为备份，又可以让其他人通过仓库来协作，真是一举多得。
首先登录GitHub，然后点击右上角的加号“Create a new rep”按钮，创建一个新的仓库：
在Repository name 中填入learngit，其它保持默认设置，点击"Create repository"按钮，就成功创建了一个新的Git仓库：
hah
现在我们要做的是将本地仓库与远程仓库关联，根据GitHub的提示，在本地的learngit仓库运行命令：
$ git remote add origin git@github.com:honeywolf/learngit.git
将honeywolf替换成自己的GitHub账户名，否则你在本地关联的是我的远程仓库，关联没有问题，但是以后推送代码是推送不了的，因为你的SSH Key公钥不再我的帐户列表中。
添加后，远程仓库的名字就是origin，这事Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。
下一步就是把本地的内容推送到远程库：
$ git push -u origin master
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 270 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@github.com:honeywolf/learngit.git
* [new branch] master -> master
Branch master set up to track remote branch master from origin.
把本地内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。
由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时可以简化命令。
从现在起，只要本地作了提交，就可以通过命令：
$ git push origin master
把本地master分支的最新修改推送至GitHub，现在，你就真正拥有了分布式版本库。
创建与合并分支
在版本回退里，我们已经知道，每次提交，Git会把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git中这个分支叫做主分支，即master分支。HEAD严格来讲并不是指向提交(commit_id)，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。
一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点。
每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。
当我们创建一个新的分支dev的时候，Git新建了一个指针叫做dev，指向master相同的提交，这样一个新的分支就诞生了。再把HEAD指向dev，就表示当前分支在dev上。这样看来Git创建分支的速度很迅猛，因为除了增加一个指针dev，改变HEAD的指向，工作区的文件都没有发生变化。
不过从现在开始，对工作区的修改和提交就是针对dev分支啦，比如新提交一次后，dev指针往前移动了一步，而master指针是不变的。
假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并分支呢？最简单的办法，就是直接把master指向dev的当前提交，就完成了合并。所以Git分支的合并也很迅捷，工作区的内容也不会发生改变。
合并完成以后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支。
下面开始实战。
首先，我们创建一个dev分支，然后切换到dev分支。
$ git checkout -b dev
Switched to a new branch 'dev'
git checkout命令加上-b参数表示创建并切换，相当于以下两条指令
$ git branch dev
$ git checkout dev
Switched to a new branch 'dev'
git branch命令会列出所有分支，当前分支前面有个*号：
$ git branch
* dev
master
然后我们在dev上可以做正常的提交，比如对readme.txt的修改，加上一行：
creating a new branch is quick
然后提交
$ git commit -a -m "branch test"
[dev e96c626] branch test
1 file changed, 2 insertions(+)
现在dev的工作完成了，我们就可以切换回master分支。
$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
现在我们切回master分支后，再查看readme.txt文件，刚才添加的内容不见了！因为那个提交实在dev分支上，而master分支此刻的提交点并没有发生变化。
现在，我们把dev的工作成果合并到master分支：
$ git merge dev -m "merge dev"
Updating e9da25c..e96c626
Fast-forward
readme.txt | 2 ++
1 file changed, 2 insertions(+)
git merge命令用于合并指定分支到当前分支。合并后，再查看 readme.txt文件内容，就可以看到，和dev分支最后提交的是完全一样的。
注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并的速度非常的快。
当然并不是每次合并都能使用Fast-forward模式，后面我们会讲道其他方式的合并。
合并完成后，就可以放心地删除dev分支了。
$ git branch -d dev
Deleted branch dev (was e96c626).
因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删除分支，这和直接在master分支上工作效果是一样的，但过程更安全。
小结
Git鼓励大量使用分支：
查看分支 git branch
创建分支 git branch <name>
切换分支 git checkout <name>
创建+切换分支 git checkout -b <name>
合并到当前分支 git merge <name>
删除分支 git branch -d <name>
解决冲突
人生不如意事有九八，合并分支往往也不是一帆分顺的。
准备新的feature1分支，继续我们的新分支开发：
$ git checkout -b feature1
Switched to a new branch 'feature1'
修改readme.txt最后一行，改为：
$ git add readme.txt
$ git commit -m "AND simple"
[feature1 8974d1b] AND simple
1 file changed, 1 insertion(+), 1 deletion(-)
切换到master分支：
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)
Git 会自动提示我们当前的master分支比远程的master分支要超前一个提交。
在master分支上把readme.txt最后一行改为：
Creating a new branch is quick & simple.
提交：
$ git add readme.txt
$ git commit -m "& simple"
[master e4a1309] & simple
1 file changed, 1 insertion(+), 1 deletion(-)
现在master分支和feature1分支各自都分别有新的提交：
在这种情况下Git无法执行快速合并，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：
$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.
果然冲突了！Git告诉我们，readme.txt文件存在冲突，必须手动解决冲突然后再提交。git status也可以告诉我们冲突的文件：
$ git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
(use "git push" to publish your local commits)
You have unmerged paths.
(fix conflicts and run "git commit")
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: readme.txt
no changes added to commit (use "git add" and/or "git commit -a")
我们可以查看readme.txt的内容：
Git is a version control system.
Git is a free software.
<<<<<<< HEAD
Create a new branch is quick & simple.
=======
Create a new branch is quick AND simple.
>>>>>>> feature1
Git使用<<<<<<<，=======，>>>>>>>标记出不同的内容，我们修改成如下后保存。
Create a new branch is quick and simple.
再提交：
$ git add readme.txt
$ git commit -m "conflic fixed"
[master 4f8be33] conflic fixed
用带参数的git log也可以看到分支的合并情况：
$ git log --graph --pretty=oneline --abbrev
* 4f8be331c4a0972055f295cf8b8c4e7cec15e8d3 conflic fixed
|\
| * 8974d1bf72c971d6904568f5ada712559a13a1b2 AND simple
* | e4a1309271c343c844caaa4217ca8724024b8642 & simple
|/
* e96c626c9adf06390a936c51e3de6723e1d2e3b3 branch test
* e9da25c20a570b2f6280d3bb47a5e0d3935a5a8b wrote a readme file
最后删除feature1分支:
$ git branch -d feature1
Deleted branch feature1 (was 8974d1b).
工作完成。
小结
当Git无法自动合并分支时，就必须首先要解决冲突。解决冲突后，再提交，合并完成。
用git log --graph命令可以看到分支合并图。
分支管理策略
通常，合并分支时，如果可能，Git会用Fast forward模式，但在这种模式下，删除分支后，会丢掉分支信息。
如果强制禁用Fast forward模式，Git会在merger时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
下面我们实战一下--no-ff方式的git merge
首先我们仍然要创建并切换dev分支
修改readme.txt文件，并提交一个新的commit：
我们切回master
准备合并dev分支，请注意--no-f参数，表示禁止使用Fast forward:
$ git merge --no-f -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
readme.txt | 1 +
1 file changed, 1 insertion(+)
因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写了进去。
合并后我们用git log查看分支历史：
$ git log --graph --pretty=oneline
* 9e2804ba5091cf25825479b4483d98d1767f31b0 merge with no-ff
|\
| * 41b696e22b98cd19baa45824a355656658a1d06d add merge
|/
* 4f8be331c4a0972055f295cf8b8c4e7cec15e8d3 conflic fixed
|\
| * 8974d1bf72c971d6904568f5ada712559a13a1b2 AND simple
* | e4a1309271c343c844caaa4217ca8724024b8642 & simple
|/
* e96c626c9adf06390a936c51e3de6723e1d2e3b3 branch test
* e9da25c20a570b2f6280d3bb47a5e0d3935a5a8b wrote a readme file
分支策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先：master分支应该是非常稳定的，也就是仅仅用来发布新版本，平时不能在上面干活；
那在哪里干活呢？干活都在dev分支上，也就是说dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上。在master上发布1.0版本。
你和你的小伙伴每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
小结
Git分支十分强大，在团队开发中应该充分应用。
合并分支时，加上--no-ff参数就可以以普通模式合并，合并后的历史分支，能看出来作了哪些合并，而Fast forward合并就看不出来曾经做过合并。
Bug分支
软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此强大。所以每个bug都可以通过一个临时分支修复，修复后合并分支，然后将临时分支删除。
当你接到一个修复代号为101的bug任务时，很自然的，你想创建一个分支issue-101来修复它。但是，先等一等，当前正在dev上进行的工作还没提交呢。
$ git status
On branch dev
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: hello.py
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
并不是你不想提交，而是工作还没有完成，还没法提交，预计完成还需一天时间。但是，必须在两个小时之内修复改bug，怎么办？
Git考虑的很周到，为我们提供了git stash功能，可以把工作区现场“存储”起来，等以后恢复现场后继续工作。
$ git stash
Saved working directory and index state WIP on dev: 41b696e add merge
HEAD is now at 41b696e add merge
现在用git status来查看情况，工作区就是干净的，除非有没有被Git管理的文件。因此你就可以放心大胆的地创建新的分支来修复bug。
首先要确定在哪个分支上修复bug，假定需要在master上修复，就从master创建临时分支：
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
(use "git push" to publish your local commits)
$ git checkout -b issue-101
Switched to a new branch 'issue-101'
现在修复bug，然后提交:
$ git add readme.txt
$ git commit -m "fix bug 101"
[issue-101 20f6aa2] fix bug 101
1 file changed, 1 insertion(+), 1 deletion(-)
修复完，切换到master分支，完成合并，删除issue-101分支：
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
(use "git push" to publish your local commits)
$ git merge --no-ff -m "merge fix bug 101" issue-101
Merge made by the 'recursive' strategy.
readme.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
$ git branch -d issue-101
Deleted branch issue-101 (was 20f6aa2).
太棒了，原计划两个小时的bug修复只花费了5分钟！现在是时候回到dev分支干活啦。
$ git checkout dev
Switched to branch 'dev'
$ git status
On branch dev
nothing to commit, working directory clean
工作区是干净的，刚才的工作现场到哪里去了？用git stash list查看
$ git stash list
stash@{0}: WIP on dev: 41b696e add merge
工作现场还在，Git把工作现场存储到了某个地方，但是需要恢复一下，有两个办法:
一是用git stash apply恢复，但是恢复后，stash内容并不清楚，你需要用git stash drop来删除；
另一种方法是用 git stash pop,恢复的同时把stash的内容也删了：
$ git stash pop
On branch dev
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: hello.py
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
Dropped refs/stash@{0} (8ba1ca0c4d887d79faba741dca8ff37fa5612fb6)
再用git stash list查看，就看不到任何stash的内容了：
$ git stash list
你可以多次stash，恢复的时候先用git stash list查看，然后恢复指定的stash，用命令：
git stash apply stash@{1}
小结
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除
当手头工作没有完成时，我们用git stash将工作区缓存，然后去修复bug。bug改完后，再git stash pop。
Feature分支
软件开发过程汇总，总有无穷尽的新功能要不断添加进来。
添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了。所以每添加一个新功能最好添加一个新的feature分支，在上面开发新功能。完成后，合并，删除该feature分支。
现在你终于接到了一个新任务：开发代号为Vulcan的新功能，该功能计划用于下一代星际飞船。
于是准备开发
$ git checkout -b feature-vulcan
Switched to a new branch 'feature-vulcan'
5分钟后，开发完毕：
$ git status
On branch feature-vulcan
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: vulcan.py
$ git commit -m "add feature vulcan"
[feature-vulcan 8f9c087] add feature vulcan
1 file changed, 1 insertion(+)
create mode 100644 vulcan.py
切回dev，准备合并：
$ git checkout dev
Switched to branch 'dev'
一切顺利的话，feature分支和bug分支是类似的，合并，然后删除。
但是，就在此时，接到上级命令，因经费不足，新功能必须取消！
虽然白干了，但是这个分支还是必须就地销毁：
$ git branch -d feature-vulcan
error: The branch 'feature-vulcan' is not fully merged.
If you are sure you want to delete it, run 'git branch -D feature- vulcan'.
Git提示，该分支未完全merge，还不能删除，如果要强行删除，需要使用git branch -D feature- vulcan命令：
现在我们强行删除：
$ git branch -D feature-vulcan
Deleted branch feature-vulcan (was 8f9c087).
小结
开发一个新的feature，最好创建一个新的分支；
如果要丢弃一个没有被合并过的分支，可以通过 git branch -D feature-vulcan强行删除。
多人协作
当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。
要查看远程仓库的信息用git remote
$ git remote
origin
或者用git remote -v显示更详细的信息：
$ git remote -v
origin git@github.com:hoenywolf/learngit.git
(frtch)
origin git@github.com:hoenywolf/learngit.git
(push)
上面显示了可以抓取和推送的origin地址。如果没有推送权限就看不到push地址。
推送分支
推送分支，就是把分支上的所有本地数据提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的分支上：
$ git push origin master
如果要推送其他分支，比如dev，就改成：
$ git push origin dev
但是，并不是一定要把本地分支往远程推送，那么哪些分支需要推送，哪些不需要呢？
-
master分支是主分支，因此要时刻与远程仓库同步； -
dev是开发分支，团队所有的成员都要在上面工作，所以也需要与远程同步； -
bug分支只用于在本地修复bug，就没必要推送到远程了，除非老板要看看你每周修复了几个bug -
feature分支是否推送到远程取决于你是否和你的伙伴合作在上面开发。
总之在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！
抓取分支
多人协作时，大家都会往master分支和dev分支上推送各自的修改。
现在模拟一个你的小伙伴，可 以在另一台电脑（注意要把SSH Key添加到GitHub）或者同一台电脑的另一个目录下克隆:
$ git clone git@github.com:honeywolf/learngit.git
当你的小伙伴从远程仓库clone时，默认情况下，你的小伙伴只能看到本地master分支。
$ git branch
* master
现在，你的小伙伴要在dev分支上开发，就必须创建远程orgin的dev分支到本地，于是他用这个命令创建本地分支:
$ git checkout -b dev origin/dev
现在，他就可以在dev分支上继续修改，然后时不时地不断把dev分支push到远程：
$ git commit -m "add /usr/bin/env"
....
$ git push origin dev
....
你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送：
$ git push origin dev
To git@github.com:honeywolf/learngit.git
! [rejected] dev -> dev (fetch first)
error: failed to push some refs to 'git@github.com:honeywolf/learngit.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用 git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送：
$ git pull
remote: Counting objects: 8, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 8 (delta 0), reused 8 (delta 0), pack-reused 0
Unpacking objects: 100% (8/8), done.
From github.com:honeywolf/learngit
a947c9b..2f95e78 dev -> origin/dev
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details
git pull <remote> <branch>
If you wish to set tracking information for this branch you can do so with:
git branch --set-upstream-to=origin/<branch> dev
git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：
$ git branch --set-upstream-to=origin/dev dev
再pull：
$ git pull
这回git pull成功，但是合并有冲突，需要手动解决，解决的办法和分支管理中解决冲突完全一样。解决后，然后提交，再push：
$ git commit -m "merge & fix hello.py"
...
$ git push origin dev
...
因此多人协作的工作模式通常是这样的：
- 首先，自己试图用
git push origin branch-name推送自己的修改； - 如果推送失败，则因为远程分支比你的本地更新，需要用
git pull试图合并 - 如果合并有冲突，则解决冲突，并在本地提交；
- 没有冲突或者解决掉冲突后，再用
git push origin brach-name推送就能成功。
如果git pull提示"no tracking information"，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream branch-name origin/branch-name。
这就是多人协作的工作模式，一旦熟悉了，就非常简单。
小结
- 查看远程库信息，使用
git remote -v； - 本地新建的分支如果不推送到远程，对其他人就是不可见的；
- 从本地推送分支，使用
git push origin branch-name,如果推送失败先用git pull抓取远程的最新提交； - 在本地创建和远程分支对应的分支，使用
git checkout -b branch-name origin/branch-name,本地和远程分支的名称最好一致； - 建立本地分支和远程分支的关联，使用
git branch --set-upstream-to=origin/<branch-name> <branch-name> - 从远程抓取分支，使用
git pull，如果有冲突，要先处理冲突。
标签管理
发布一个版本时，我们通常在版本库中打一个标签，这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取这个标签的版本，就是把那个打标签时刻的历史版本取出来。所以标签也是版本库的一个快照。
Git标签虽然是版本库的快照，但其实它就是指向某个commit 指针（跟分支很像对不对？但是分支是可以移动的，标签不可以移动）所以，创建和删除标签都是瞬间完成的。
创建标签
在Git中打标签非常简单，首先，切换到需要打标签的分支上：
$ git branch
* dev
master
$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
然后敲命令git tag <name>就可以打一个新标签：
$ git tag v1.0
可以用git tag命令查看所有的标签
$ git tag
v1.0
默认的标签都是打在最新的commit提交上的。有时候，会忘记打标签。比如现在已经周五了，但应该在周一打的标签没有打，该怎么办呢？
方法是找到历史提交的 commit id,然后打上就可以了：
$ git log --pretty=oneline --abbrev-commit
4e90863 merge fix bug 101
20f6aa2 fix bug 101
9e2804b merge with no-ff
41b696e add merge
4f8be33 conflic fixed
e4a1309 & simple
8974d1b AND simple
e96c626 branch test
e9da25c wrote a readme file
比方说要对add merge这次提交打标签，它对应的commit id 是41b696e，敲入命令
$ git tag v0.9 41b696e
$ git tag
v0.9
v1.0
注意标签不是按时间顺序列出，而是按字母排序的。可以用git show <tagname>查看标签信息：
$ git show v0.9
commit 41b696e22b98cd19baa45824a355656658a1d06d
Author: honeywolf <adam.h@gmail.com>
Date: Fri Mar 11 23:42:57 2016 +0800
add merge
...
可以看到，v0.9确实打在add merge这次提交上。
还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字：
$ git tag -a v0.1 -m "version 0.1 released" 20f6aa220
用命令git show <tagname>可以看到说明文字
$ git show v0.1
tag v0.1
Tagger: honeywolf <adam.h@gmail.com>
Date: Sat Mar 12 14:56:11 2016 +0800
version 0.1 released
commit 20f6aa22033491f033d54efe1088fc04e7fbff38
Author: honeywolf <adam.h@gmail.com>
Date: Sat Mar 12 00:16:50 2016 +0800
fix bug 101
还可以通过-s用私钥签名一个标签：
$ git tag -s v0.2 -m "signed version 0.2 released" 4e90863dc
签名采用PGP签名，因此，必须首先安装gpg（GnuPG），如果没有找到gpg，或者没有gpg密钥对，就会报错：
error: cannot run gpg: No such file or directory
error: could not run gpg.
error: unable to sign the tag
如果报错，请参考GnuPG
小结
- 命令
git tag <name>用于新建一个标签，默认为HEAD，也可以指定一个commit id； -
git tag -a <tagname> -m "balabalabala..."可以指定标签信息； -
git tag -s <tagname> -m "balabalabala..."可以用PGP签名标签； - 命令
git tag可以查看所有标签。
操作标签
如果标签打错了，可以删除：
$ git tag -d v0.1
Deleted tag 'v0.1' (was c9e4c38)
因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。
如果要推送到远程，使用命令git push origin <tagname>：
$ git push origin v1.0
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:honeywolf/learngit.git
* [new tag] v1.0 -> v1.0
或者一次性推送全部尚未推送到远程的本地标签：
git push origin --tags
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:honeywolf/learngit.git
* [new tag] v0.9 -> v0.9
如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除：
git tag -d v0.9
Deleted tag 'v0.9' (was 41b696e)
然后从远程删除。删除命令也是push，但是格式如下：
$ git push origin :refs/tags/v0.9
To git@github.com:honeywolf/learngit.git
- [deleted] v0.9
要看看是否真的从远程删除了标签，可以登录GitHub查看。
小结
- 命令
git push origin <tagname>可以推送一个本地标签 - 命令
git push origin --tags可以推送全部未推送过的本地标签； - 命令
git tag -d <tagname>可以删除一个本地标签； - 命令
git push origin :refs/tags/<tagname>可以删除一个远程标签。
使用GitHub
我们一直用GitHub作为免费的仓库，如果是个人开源项目，放到GitHub上是完全没有问题的。其实GitHub还是一个开源协作社区，通过GitHub，即可以让别人参与你的 开源项目，也可以参与别人的开源项目。
在GitHub出现以前，开源项目开源容易，但让广大人民群众参与进来比较困难，因为要参与，就要提交代码，而给每个想提交代码的群众都开一个账号那是不现实的，因此，群众也仅限于报个bug，即使能改掉bug，也只能把diff文件用邮件发过去，很不方便。
但是在GitHub上，利用Git及其强大的克隆和分支功能，广大人民群众真正可以第一次自由参与各种开源项目了。
如何参与一个开源项目呢？比如人气极高的booststrap项目，这是一个非常强大的CSS框架，你可以访问它的项目主页https://github.com/twbs/bootstrap，点击"Fork"就在自己的帐号下克隆了一个bootstrap仓库，然后，从自己的帐号下clone：
git clone git@github.com:honeywolf/bootstrap.git
一定要从自己的帐号下clone仓库，这样你才能推送修改。如果从bootstrap作者的仓库地址git@github.com:twbs/bootstrap.git克隆，因为没有权限，你将不能推送修改。
如果你希望修复bootstrap的一个bug，或者新增一个功能，立刻就可以开始干活，干完后，往自己的仓库推送。
如果你希望bootstrap的官方库能接受你的修改，你就可以在GitHub上发起一个pull request。当然，对方是否接受你的pull request就不一定了。
小结
- 在GitHub上，可以任意Fork开源仓库；
- 自己拥有Fork后的仓库的读写权限；
- 可以推送pull request给官方仓库来贡献代码。
自定义Git
在安装Git一节中，我们已经配置了user.name和user.email，实际上，Git还有很多可配置项。比如，让Git显示颜色，会让命令输出看起来更醒目：
$ git status
On branch dev
Your branch is up-to-date with 'origin/dev'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: readme.txt
文件名就会标上颜色。我们后序还会介绍如何更好的配置Git，以便让你的工作更高效。
忽略特殊文件
有些时候，你必须把某些文件放到Git工作目录中，但是又不想提交它们，比如保存了数据库密码的配置文件啦，等等，每次git status都会显示Untracked files ...，有强迫症的童鞋心里肯定不爽。
好在Git考虑到了大家的感受，这个问题解决起来也很简单，在Git工作区的根目录下创建一个特殊的.gitignore文件，GitHub已经为我们准备了各种配置文件，只要组合一下就可以使用了。所有配置文件可以直接在线浏览：https://github.com/github/gitignore
忽略文件的原则是：
- 忽略操作系统自动生成的文件，比如缩略图等；
- 忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的
.class文件； - 忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件。
举个例子：
假设你在Windows下进行Python开发，Windows会自动在有图片的目录下生成隐藏的缩略图文件，如果有自定义目录，目录下就会有Desktop.ini文件，因此你需要忽略Windows自动生成的垃圾文件：
# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini
然后，继续忽略Python编译产生的.pyc、.pyo、dist等文件或目录：
# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build
加上你自己定义的文件，最终得到一个完整的.gitignore文件，内容如下：
# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini
# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build
# My configurations:
db.ini
deploy_key_rsa
最后一步就是把.gitignore也提交到Git，就完成了！当然检验.gitignore的标准是git status命令是不是说working directory clean。
使用Windows的童鞋注意了，如果你在资源管理器里新建一个.gitignore文件，它会非常弱智地提示你必须输入文件名，但是在文本编辑器里“保存”或者“另存为”就可以把文件保存为.gitignore了。
OC语言的.gitignore
# Xcode
#
# gitignore contributors: remember to update Global/Xcode.gitignore, Objective-C.gitignore & Swift.gitignore
## Build generated
build/
DerivedData/
## Various settings
*.pbxuser
!default.pbxuser
*.mode1v3
!default.mode1v3
*.mode2v3
!default.mode2v3
*.perspectivev3
!default.perspectivev3
xcuserdata/
## Other
*.moved-aside
*.xcuserstate
## Obj-C/Swift specific
*.hmap
*.ipa
# CocoaPods
#
# We recommend against adding the Pods directory to your .gitignore. However
# you should judge for yourself, the pros and cons are mentioned at:
# https://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control
#
# Pods/
# Carthage
#
# Add this line if you want to avoid checking in source code from Carthage dependencies.
# Carthage/Checkouts
Carthage/Build
# fastlane
#
# It is recommended to not store the screenshots in the git repo. Instead, use fastlane to re-generate the
# screenshots whenever they are needed.
# For more information about the recommended setup visit:
# https://github.com/fastlane/fastlane/blob/master/docs/Gitignore.md
fastlane/report.xml
fastlane/screenshots
小结
- 忽略某些文件时，需要编写.gitignore；
- .gitignore文件本身要放到版本库里，并且可以对.gitignore做版本管理！
配置别名
有没有经常敲错命令？比如git status? status这个单词真心不好记。
如果敲git st就表示git status那就简单多了，当然这种偷懒的办法我们是极力赞成的。
我们只需要敲一行代码，告诉Git，以后st就是status:
$ git config --global alias.st status
当然还有别的命令可以简写，很多人都用co表示checkout，ci表示commit，br表示branch：
$ git config --global alias.co checkout
$ git config --global alias.ci commit
$ git config --global alias.br branch
--global参数是全局参数，也就是这些命令在这台电脑的所有Git仓库下都有用。
在撤销修改一节中，我们知道，命令git reset HEAD file可以把暂存区的修改撤销掉（unstage），重新放回工作区。既然是一个unstage操作，就可以配置一个unstage别名：
$ git config --global alias.unstage 'reset HEAD'
配置一个git last，让其显示最后一次提交信息：
$ git config --global alias.last 'log -1'
甚至还有人丧心病狂地把lg配置成了：
git config --global alias.lg "log --color --graph -- pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"
配置文件
配置Git的时候，加上--global是针对当前用户起作用的，如果不加，那只针对当前的仓库起作用。
配置文件放哪了？每个仓库的Git配置文件都放在.git/config文件中：
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
precomposeunicode = true
[remote "origin"]
url = git@github.com:honeywolf/learngit.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[branch "dev"]
remote = origin
merge = refs/heads/dev
别名就在[alias]后面，要删除别名，直接把对应的行删掉即可。
而当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig中：
$ cat .gitconfig
[filter "lfs"]
clean = git-lfs clean %f
smudge = git-lfs smudge %f
required = true
[user]
name = honeywolf
email = adam.honey@ydx.hk
[color]
ui = true
[alias]
st = status
co = checkout
ci = commit
br = branch
unstage = reset HEAD
last = log -1
lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
配置别名也可以直接修改这个文件，如果改错了，可以删掉文件重新通过命令配置。
小结
给Git配置好别名，就可以输入命令时偷个懒。我们鼓励偷懒 。
网友评论