Git系列二之数据管理

1.Git基本管理

git常用的基本操作

1.1提交数据

我们可以简单的把工作目录理解成是一个被Git服务程序管理的目录，Git会时刻的追踪目录内文件的改动，另外在安装好了Git服务程序后，默认就会创建好了一个叫做master的分支，我们直接可以提交数据到了

1.创建本地工作目录demo，并初始化为git工作目录

[root@git-node1 ~]# mkdir demo
[root@git-node1 ~]# cd demo/
[root@git-node1 git-demo]# git init
Initialized empty Git repository in /root/demo/.git/

2.创建readme.txt文件

[root@rabbitmq demo]# vi index.html
welcome nulige

3.查看git状态

[root@rabbitmq demo]# git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   index.html
#
no changes added to commit (use "git add" and/or "git commit -a")

4.提示使用git add添加文件至暂存区

[root@rabbitmq demo]# git add index.html  #添加到暂存区
 
[root@rabbitmq demo]# git status   #查看变更状态
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   index.html
#

5.使用git cmmit提交暂存区文件至git版本仓库 -m:提交描述信息(提交至远程需添加远程仓库)

[root@git-node1 demo]# git commit -m "the first commit index.html"
[master（根提交） 85bd268] the first commit index.html
 file changed,  insertions(+),  deletions(-)
create mode  index.html

1.2移除数据

有些时候会将已经添加到暂存区的文件移除，但仍然希望文件在工作目录中不丢失，换句话说，就是把文件从追踪清单中删除。

1.建立新文件

[root@git-node1 demo]# vi index.php

Hello nuloge

2.添加新文件至暂存区

[root@git-node1 demo]# git add index.php    #添加到暂存区
[root@git-node1 demo]# git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   index.php
#

3.将新文件从暂存区撤出(并不会删除工作目录内的数据)

[root@git-node1 demo]# git add index.php  #文件添加到暂存区
 
[root@git-node1 demo]# git status   #查看文件状态
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   index.php
 
[root@git-node1 demo]# git reset HEAD index.php   #从暂存区撤消文件
 
[root@git-node1 demo]# git status //index.php   #文件状态为未跟踪
fatal: '//index.php' is outside repository
 
[root@git-node1 demo]# git status  #查看文件状态
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       index.php
nothing added to commit but untracked files present (use "git add" to track)
#提交为空，但是存在尚未跟踪的文件（使用 "git add" 建立跟踪）
 
#如果想将文件数据从git暂存区和工作目录一起删除，可以做如下操作。

[root@git-node1 demo]# git add index.php  #添加文件到暂存区
 
[root@git-node1 demo]# git rm index.php   #文件已经放入暂存区域,防止误删
error: 'index.php' has changes staged in the index   #有变更已暂存至索引中
(use --cached to keep the file, or -f to force removal)
#（使用 --cached 保存文件，或用 -f 强制删除）
 
[root@git-node1 demo]# git rm -f index.php  #使用追加强制删除-f参数或者-cache保存
rm 'index.php'
 
[root@git-node1 demo]# git status #查看当前状态
# On branch master #位于分支 master
nothing to commit (working directory clean)  #无文件要提交，干净的工作区
 
[root@git-node1 demo]# ls   #文件已经不存在
index.html

1.3移动数据

有些时候会将已经添加到暂存区的文件重新修改名称，可使用如下操作完成。 
1.git重新命名文件名称，使用git mv操作。

[root@git-node1 demo]# ls
index.html
[root@git-node1 demo]# git mv index.html index.php

2.使用git status查看更改状态

[root@git-node1 demo]# git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       renamed:    index.html -> index.php
#

3.使用git commit 提交git仓库,并描述提交信息

[root@git-node1 demo]# git commit -m "chaned name index.html->index.php"
[master ca24753] chaned name index.html->index.php
  files changed,  insertions(+),  deletions(-)
 rename index.html => index.php (%)

1.4历史数据

在提交了若干更新之后，想回顾下提交历史，可以使用 git log 命令查看提交历史记录。 
1.查看提交历史记录

[root@git-node1 demo]# git log
commit ca24753faac356ae926c89f6d8c2da2ee69d67ec
Author: nulige <nulige@nulige.com>
Date:   Mon May  ::  +
 
    chaned name index.html->index.php
 
commit 90596d4d1fdcc37e175d18778e2f07a98c42f86b
Author: root <root@git-node1.(none)>
Date:   Mon May  ::  +
 
    the first commit index.html

2.查看历史1次提交记录

# -n  (n是一个正整数)，查看最近n次的提交信息
 
[root@git-node1 demo]# git log -
commit ca24753faac356ae926c89f6d8c2da2ee69d67ec
Author: nulige <nulige@nulige.com>
Date:   Mon May  ::  +
 
    chaned name index.html->index.php
 
commit 90596d4d1fdcc37e175d18778e2f07a98c42f86b
Author: root <root@git-node1.(none)>
Date:   Mon May  ::  +
 
    the first commit index.html

3.显示提交的内容差异,例如仅查看最近2次差异

[root@git-node1 demo]# git log -p -2  #显示最近二次更新
commit ca24753faac356ae926c89f6d8c2da2ee69d67ec
Author: nulige <nulige@nulige.com>
Date:   Mon May  ::  +
 
    chaned name index.html->index.php
 
diff --git a/index.html b/index.html
deleted file mode
index 6e599f4..
--- a/index.html
+++ /dev/null
@@ - +, @@
-welcome nulige
diff --git a/index.php b/index.php
new file mode
index ..6e599f4
--- /dev/null
+++ b/index.php
@@ -, + @@
+welcome nulige
 
:
commit ca24753faac356ae926c89f6d8c2da2ee69d67ec
Author: nulige <nulige@nulige.com>
Date:   Mon May  ::  +
 
    chaned name index.html->index.php
 
diff --git a/index.html b/index.html
deleted file mode
index 6e599f4..
--- a/index.html
+++ /dev/null
@@ - +, @@
-welcome nulige
diff --git a/index.php b/index.php
new file mode
index ..6e599f4
--- /dev/null
+++ b/index.php
@@ -, + @@
+welcome nulige
 
commit 90596d4d1fdcc37e175d18778e2f07a98c42f86b
Author: root <root@git-node1.(none)>
Date:   Mon May  ::  +
 
: 退出按 q

4.简要显示数据修改行数

#--stat: 列出文件的修改行数
[root@git-node1 demo]# git log --stat
commit ca24753faac356ae926c89f6d8c2da2ee69d67ec
Author: nulige <nulige@nulige.com>
Date:   Mon May  ::  +
 
    chaned name index.html->index.php
 
 index.html |     -
 index.php  |     +
  files changed,  insertions(+),  deletions(-)
 
commit 90596d4d1fdcc37e175d18778e2f07a98c42f86b
Author: root <root@git-node1.(none)>
Date:   Mon May  ::  +
 
    the first commit index.html
 
 index.html |     +
  files changed,  insertions(+),  deletions(-)

 

5.根据不同的格式展示提交的历史信息

 [root@git-node1 demo]# git log --pretty=oneline
 95734131860ef7c9078b8a208ff6437d0952380b chnged name index.html->index.php
 85bd2680bd4b70aeded9dbd230c07ab086712ff9 the first commit index.htm
 可以使用format参数来指定具体的输出格式，这样非常便于后期编程的提取分析哦，常用的格式有：
 %s 提交说明。
 %cd 提交日期。
 %an 作者的名字。
 %cn 提交者的姓名。
 %ce 提交者的电子邮件。
 %H 提交对象的完整SHA-1哈希字串。
 %h 提交对象的简短SHA-1哈希字串。
 %T 树对象的完整SHA-1哈希字串。
 %t 树对象的简短SHA-1哈希字串。
 %P 父对象的完整SHA-1哈希字串。
 %p 父对象的简短SHA-1哈希字串。
 %ad 作者的修订时间。
 定制详细的日志输出
 [root@git-node1 demo]# git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset %cn"' --abbrev-commit --date=relative
 * 5f3f588 - (HEAD, origin/master, –r, tt, master) merge branch linux readme.txt ( 分钟之前) xulia
 |\
 | * 4580c3b - (linux) touch readme.txt ( 分钟之前) xuliangwei"
 * | 4c7a145 - touch readme.txt ( 分钟之前) xuliangwei"
 |/
 *  - (tag: v1.0.0) chnged name index.html->index.php ( 小时之前) xuliangwei"
 * 85bd268 - the first commit index.html ( 小时之前) xuliangwei"
 配置.git/config文件，增加如下2行，以后即可使用 git hlog代替如上复杂命令
 [root@git-node1 demo]# tail - .git/config
 [alias]
 hlog = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset %cn' --abbrev-commit --date=relative
 //以后使用git hlog即可实现复杂的命令
  

1.5还原数据(称为：回滚)

将文件hello boos写成了hello nulige，但是已经提交至远程仓库，现在想要撤回重新提交。 
（本小结涉及远程仓库,可先学习后面章节，在回头学习本章节） 
1.查看index.html文件

[root@git-node1 demo]# git checkout -b dev //内容存在dev分支
[root@git-node1 demo]# cat index.html
hello boss
[root@git-node1 demo]# echo "hello nulige" >> index.html

2.追加内容至index.html，并提交至远程仓库

[root@git-node1 demo]# git add index.html
[root@git-node1 demo]# git commit -m "hello nulige"
[master ] boss dou
 file changed,  insertion(+)
[root@git-node1 demo]# git push origin dev
Counting objects: , done.
Compressing objects: % (/), done.
Writing objects: % (/),  bytes |  bytes/s, done.
Total  (delta ), reused  (delta )
To git@git-node1:root/git_demo.git
507bf99.. dev -> dev

3.此时觉得写的不妥，想还原上一次提交的文件快照，找出历史信息

[root@git-node1 demo]# git log -
*  - (HEAD, origin/dev, dev) boss dou ( 分钟之前) nulige
* 507bf99 - hello ( 分钟之前) nulige

4.回滚：找到历史还原点的值后，就可以还原(值不写全,系统会自动匹配)

[root@git-node1 demo]# git reset --hard 507bf99   #从暂存区那个点，回滚到工作区
HEAD 现在位于 507bf99 hello
[root@git-node1 nulige]# git push origin dev -f //强制推送至dev分支
[root@git-node1 demo]# cat index.html
hello boss

5、git reflog 用来记录你的每一次命令

[root@git-node1 Bastion-of-machine]# git reflog
08f962f HEAD@{}: commit (initial): first commit

1.6 删除操作

在Git中，删除也是一个修改操作，我们实战一下，先添加一个新文件test.txt到Git并且提交：

[root@git-node1 demo]# vi test.txt
I am nulige

添加到暂存区

[root@git-node1 demo]# git add .
[root@git-node1 demo]# git commit -m "add test.txt"
[master ac0cb7b] add test.txt
  files changed,  insertions(+),  deletions(-)
 create mode  Bastion-of-machine
 create mode  test.txt

一般情况下，你通常直接在文件管理器中把没用的文件删了，或者用rm命令删了

[root@git-node1 demo]# rm test.txt
rm：是否删除普通文件 "test.txt"？  #回车

#这个时候，Git知道你删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻告诉你哪些文件被删除了：
[root@git-node1 demo]# git status
# On branch master
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       deleted:    index.php
#       deleted:    test.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

现在你有两个选择，一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit：

[root@git-node1 demo]# ll
总用量
drwxr-xr-x  root root  5月    : Bastion-of-machine
-rw-r--r--  root root    5月    : test.txt
 
[root@git-node1 demo]# rm test.txt
rm：是否删除普通文件 "test.txt"？
 
[root@git-node1 demo]# git rm test.txt
rm 'test.txt'
 
[root@git-node1 demo]# git commit -m "remove test"
[master 7b5310a] remove test
  files changed,  insertions(+),  deletions(-)
 delete mode  test.txt

现在，文件就从版本库中被删除了。

另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：

[root@git-node1 demo]# git checkout -- test.txt

git checkout 其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。

1.7、理解工作区和暂存区

Git和其他版本控制系统如SVN的一个不同之处就是有暂存区的概念。

先来看名词解释。

工作区（Working Directory）

就是你在电脑里能看到的目录，比如我的git_trainning文件夹就是一个工作区：

1 2	$ ls git_trainning/ first_git_file.txt

版本库（Repository）

工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。

Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

分支和HEAD的概念我们以后再讲。

前面讲了我们把文件往Git版本库里添加的时候，是分两步执行的：

第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；

第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。

因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。

你可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。

俗话说，实践出真知。现在，我们再练习一遍，先对first_git_file.txt做个修改，比如加上一行内容：

1 2 3 4 5 6

First time using git, excited! update ... insert line here..改之前的. 第一次用git哈哈 insert line again haha... 加点新内容 update v5

然后，在工作区新增一个readme.md文本文件（内容随便写）。

先用git status查看一下状态：

1 2 3 4 5 6 7 8 9 10 11 12 13 14

$ git status On branch master 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:   first_git_file.txt   Untracked files:   (use "git add <file>..." to include in what will be committed)       readme.md   no changes added to commit (use "git add" and/or "git commit -a")

Git非常清楚地告诉我们，first_git_file.txt被修改了，而readme.md还从来没有被添加过，所以它的状态是Untracked。

现在，使用命令git add . ，再用git status再查看一下：

1 2 3 4 5 6 7 8 9

$ git add . $ git status On branch master Changes to be committed:   (use "git reset HEAD <file>..." to unstage)       modified:   first_git_file.txt     new file:   readme.md </file>

现在，暂存区的状态就变成这样了：

(盗图关系， 这里readme.txt = first_git_file.txt , LICENSE = readme.md)

所以，git add命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支。

1 2 3 4

$ git commit -m "知道暂存区stage的意思了" [master 9d65cb2] 知道暂存区stage的意思了  2 files changed, 2 insertions(+)  create mode 100644 readme.md

一旦提交后，如果你又没有对工作区做任何修改，那么工作区就是“干净”的：

1 2 3

$ git status On branch master nothing to commit, working directory clean

现在版本库变成了这样，暂存区就没有任何内容了：

(盗图关系， 这里readme.txt = first_git_file.txt , LICENSE = readme.md)

 暂存区是Git非常重要的概念，弄明白了暂存区，就弄明白了Git的很多操作到底干了什么。

1.8、远程仓库

注册一个GitHub账号,就可以免费获得Git远程仓库。

由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的，所以，需要一点设置：

第1步：创建SSH Key。在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：

[root@git-node1 demo]# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
::9f:cd::e5:c1:7c:b2:e9:6b:::e3:f8:2a root@git-node1
The key's randomart image is:
+--[ RSA ]----+
|    .   .+o      |
|     o * .+..    |
|      = + .= .   |
|       . .o + .  |
|        S. + o   |
|       .  + .    |
|           +     |
|        E o .    |
|         o..     |
+-----------------+
[root@git-node1 demo]# ls ~/.ssh/
id_rsa  id_rsa.pub
 
[root@git-node1 demo]# cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA0twNMooyMj25MeCKQoBcarKeXpPSy3mGDnmFeE0qrZ+jqQ8O8DSqaQYXVUPov3axtDS6Sdq+J63fXmZksuMYAWIRzHXzqwyKgU/exu1HAf+
/UwN/nrS1wAVEPEZM5+yutFSnUpZG0Nr2lTyTHnNBugBXr/xyxDtJErOkSbKXwzJevVIYElcLOZMfsWvJBF/zqfgvdAr6bh7nmnyEguiXL6l5CmcC7k5A/WGqFUJRzhFtNK5hTGp6YBsMBv
j3fyr9+nPexMf7TuJO3HvGps0rW0EsXJD092EO4k8cUKwVtlNoonpRChKapyRDQW1kA9dewUGdU/uRsVcCamEyp98b8w== root@git-node1

可以在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。

第2步：登陆GitHub，打开“Account settings”，“SSH Keys”页面：

然后，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容：

点“Add Key”，你就应该看到已经添加的Key

　　为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。

　　当然，GitHub允许你添加多个Key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了。

　　最后友情提示，在GitHub上免费托管的Git仓库，任何人都可以看到喔（但只有你自己才能改）。所以，不要把敏感信息放进去。

　　如果你不想让别人看到Git库，有两个办法，一个是交点保护费，让GitHub把公开的仓库变成私有的，这样别人就看不见了（不可读更不可写）。另一个办法是自己动手，搭一个Git服务器，因为是你自己的Git服务器，所以别人也是看不见的。这个方法我们后面会讲到的，相当简单，公司内部开发必备。

确保你拥有一个GitHub账号后，我们就即将开始远程仓库的学习。

1.9、分支管理

分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习Git的时候，另一个你正在另一个平行宇宙里努力学习SVN。

如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，结果，你既学会了Git又学会了SVN！

分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

其他版本控制系统如SVN等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分支比蜗牛还慢，简直让人无法忍受，结果分支功能成了摆设，大家都不去用。

但Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。

2.0、创建与合并分支

在学习版本回退部分时，你已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

下面开始实战。

首先，我们创建dev分支，然后切换到dev分支：

1 2	$ git checkout -b dev Switched to a new branch 'dev'

git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：

1 2 3

$ git branch dev $ git checkout dev Switched to branch 'dev'

然后，用git branch命令查看当前分支：

1 2 3

$ git branch * dev   master

git branch命令会列出所有分支，当前分支前面会标一个*号。

然后，我们就可以在dev分支上正常提交，比如对readme.txt做个修改，加上一行：

1	Creating a new branch is quick.

然后提交：

1 2 3 4

$ git add readme.txt $ git commit -m "branch test" [dev fec145a] branch test  1 file changed, 1 insertion(+)

现在，dev分支的工作完成，我们就可以切换回master分支：

1 2	$ git checkout master Switched to branch 'master'

切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而master分支此刻的提交点并没有变：

现在，我们把dev分支的工作成果合并到master分支上：

1 2 3 4 5

$ git merge dev Updating d17efd8..fec145a Fast-forward  readme.txt |    1 +  1 file changed, 1 insertion(+)

git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。

注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。

当然，也不是每次合并都能Fast-forward，我们后面会讲其他方式的合并。

合并完成后，就可以放心地删除dev分支了：

1 2	$ git branch -d dev Deleted branch dev (was fec145a).

删除后，查看branch，就只剩下master分支了：

1 2	$ git branch * master

因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。

解决冲突

人生不如意之事十之八九，合并分支往往也不是一帆风顺的。

准备新的feature1分支，继续我们的新分支开发：

1 2	$ git checkout -b feature1 Switched to a new branch 'feature1'

修改readme.txt最后一行，改为：

1	added this line from branch feature 1

在feature1分支上提交：

$ git add readme.txt
$ git commit -m "add feature"
[feature1 75a857c] 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.

Git还会自动提示我们当前master分支比远程的master分支要超前1个提交。

在master分支上把readme.txt文件的最后一行改为：

1	added this line from master

提交：

$ git add readme.txt
$ git commit -m "master update"
[master 400b400] & simple
 1 file changed, 1 insertion(+), 1 deletion(-)

现在，master分支和feature1分支各自都分别有新的提交，变成了这样：

这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：

1 2 3 4

$ 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也可以告诉我们冲突的文件：

1 2 3 4 5 6 7 8 9 10

$ git status # On branch master # Your branch is ahead of 'origin/master' by 2 commits. # # Unmerged paths: #   (use "git add/rm <file>..." as appropriate to mark resolution) # #       both modified:      readme.txt # no changes added to commit (use "git add" and/or "git commit -a")

我们可以直接查看readme.txt的内容：

1 2 3 4 5 6 7

#git study repo Creating a new branch is quick. <<<<<<< HEAD added this line from master ======= added this line from branch feature 1 >>>>>>> feature1

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存：

1 2 3 4

#git study repo Creating a new branch is quick. added this line from master added this line from branch feature 1

再提交

1 2 3

$ git add readme.txt $ git commit -m "conflict fixed" [master 59bc1cb] conflict fixed

现在，master分支和feature1分支变成了下图所示：

用带参数的git log也可以看到分支的合并情况：

1 2 3 4 5 6 7 8

$ git log --graph --pretty=oneline *   feedd786cad3e18323a41846fcc1b0d52fc0c98e fix conflict |\  | * 01f8f8d168e113fac9fbe24c4cfa6d4c351a9821 update from branch * | 743ccee30f3d74f1993f17e7312032b7399b1306 from master |/  * edfbc29982927236596539e0f1971b0575f803c0 branch test * 8675486bfeeb340914369e80d2cfcf3e854e88a3 add home page

　　

2.1、分支策略

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

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

2.2、bug分支　　

软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交：

1 2 3 4 5 6 7 8 9 10 11 12 13

$ 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 #

　　

并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？

幸好，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

1 2 3

$ git stash Saved working directory and index state WIP on dev: 6224937 add merge HEAD is now at 6224937 add merge

现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。

首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：

1 2 3 4 5

$ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 6 commits. $ git checkout -b issue-101 Switched to a new branch 'issue-101'

现在修复bug，需要把“Git is free software ...”改为“Git is a free software ...”，然后提交：

1 2 3 4

$ git add readme.txt $ git commit -m "fix bug 101" [issue-101 cc17032] fix bug 101  1 file changed, 1 insertion(+), 1 deletion(-)

修复完成后，切换到master分支，并完成合并，最后删除issue-101分支：

1 2 3 4 5 6 7 8 9

$ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 2 commits. $ git merge --no-ff -m "merged bug fix 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 cc17032).

　　

太棒了，原计划两个小时的bug修复只花了5分钟！现在，是时候接着回到dev分支干活了！

1 2 3 4 5

$ git checkout dev Switched to branch 'dev' $ git status # On branch dev nothing to commit (working directory clean)

　　

工作区是干净的，刚才的工作现场存到哪去了？用git stash list命令看看：

1 2	$ git stash list stash@{0}: WIP on dev: 6224937 add merge

工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：

一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；

另一种方式是用git stash pop，恢复的同时把stash内容也删了：

1 2 3 4 5 6 7 8 9 10 11 12 13 14

$ 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} (f624f8e5f082f2df2bed8a4e09c12fd2943bdd40)

再用git stash list查看，就看不到任何stash内容了：

1	$ git stash list

你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：

1	$ git stash apply stash@{0}

2.3、分支策略

多人协作　　

当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。

要查看远程库的信息，用git remote：

1 2	$ git remote origin

或者，用git remote -v显示更详细的信息：

1 2 3

$ git remote -v origin  git@github.com:triaquae/gitskills.git (fetch) origin  git@github.com:triaquae/gitskills.git (push)

上面显示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。

2.4、 推送分支

推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：

1	$ git push origin master

如果要推送其他分支，比如dev，就改成：

1	$ git push origin dev

但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？

• master分支是主分支，因此要时刻与远程同步；

• dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；

• bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；

• feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！

2.5、抓取分支

多人协作时，大家都会往master和dev分支上推送各自的修改。

现在，模拟一个你的小伙伴，可以在另一台电脑（注意要把SSH Key添加到GitHub）或者同一台电脑的另一个目录下克隆：

1 2 3 4 5 6 7

$ git clone git@github.com:triaquae/gitskills.git Cloning into 'gitskills'... remote: Counting objects: 16, done. remote: Compressing objects: 100% (7/7), done. remote: Total 16 (delta 0), reused 10 (delta 0), pack-reused 0 Receiving objects: 100% (16/16), done. Checking connectivity... done.

当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看：

1 2	$ git branch * master

现在，你的小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支：

1	$ git checkout -b dev origin/dev

现在，他就可以在dev上继续修改，然后，时不时地把dev分支push到远程：

1 2 3 4 5 6 7 8 9 10 11 12 13

$ git add . $ git commit -m "small updates"   [dev f1b762e] small updates  2 files changed, 5 insertions(+), 1 deletion(-) Alexs-MacBook-Pro:gitskills alex$ git push origin dev Counting objects: 4, done. Delta compression using up to 8 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (4/4), 438 bytes | 0 bytes/s, done. Total 4 (delta 0), reused 0 (delta 0) To git@github.com:triaquae/gitskills.git    33ec6b4..f1b762e  dev -> dev

　　

你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

$ git add . $ git commit -m "add Dog class" [dev 7e7b1bf] add Dog class  2 files changed, 7 insertions(+)     $ git push origin dev   To git@github.com:triaquae/gitskills.git  ! [rejected]        dev -> dev (fetch first) error: failed to push some refs to 'git@github.com:triaquae/gitskills.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抓下来，然后，在本地合并，解决冲突，再推

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

$ git pull remote: Counting objects: 4, done. remote: Compressing objects: 100% (3/3), done. remote: Total 4 (delta 0), reused 4 (delta 0), pack-reused 0 Unpacking objects: 100% (4/4), done. From github.com:triaquae/gitskills    33ec6b4..f1b762e  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的链接：

1 2	$ git branch --set-upstream-to=origin/dev dev Branch dev set up to track remote branch dev from origin.

再pull：

1 2 3 4 5 6

$ git pull Auto-merging hello.py CONFLICT (content): Merge conflict in hello.py Auto-merging branch_test.md CONFLICT (content): Merge conflict in branch_test.md Automatic merge failed; fix conflicts and then commit the result.

这回git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push：　　

1 2 3 4 5 6 7 8 9 10 11 12 13 14

$ git add . $ git commit -m "merge & fix hello.py" [dev 93e28e3] merge & fix hello.py   $ git push origin dev   Counting objects: 8, done. Delta compression using up to 8 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (8/8), 819 bytes | 0 bytes/s, done. Total 8 (delta 1), reused 0 (delta 0) remote: Resolving deltas: 100% (1/1), done. To git@github.com:triaquae/gitskills.git    f1b762e..93e28e3  dev -> dev

因此，多人协作的工作模式通常是这样：

1. 首先，可以试图用git push origin branch-name推送自己的修改；

2. 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；

3. 如果合并有冲突，则解决冲突，并在本地提交；

4. 没有冲突或者解决掉冲突后，再用git push origin branch-name推送就能成功！

如果git pull提示“no tracking information”，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream branch-name origin/branch-name。

这就是多人协作的工作模式，一旦熟悉了，就非常简单。　

2.6、 github使用

我们一直用GitHub作为免费的远程仓库，如果是个人的开源项目，放到GitHub上是完全没有问题的。其实GitHub还是一个开源协作社区，通过GitHub，既可以让别人参与你的开源项目，也可以参与别人的开源项目。

在GitHub出现以前，开源项目开源容易，但让广大人民群众参与进来比较困难，因为要参与，就要提交代码，而给每个想提交代码的群众都开一个账号那是不现实的，因此，群众也仅限于报个bug，即使能改掉bug，也只能把diff文件用邮件发过去，很不方便。

但是在GitHub上，利用Git极其强大的克隆和分支功能，广大人民群众真正可以第一次自由参与各种开源项目了。

如何参与一个开源项目呢？比如人气极高的bootstrap项目，这是一个非常强大的CSS框架，你可以访问它的项目主页https://github.com/twbs/bootstrap，点“Fork”就在自己的账号下克隆了一个bootstrap仓库，然后，从自己的账号下clone：

1	git clone git@github.com:michaelliao/bootstrap.git

一定要从自己的账号下clone仓库，这样你才能推送修改。如果从bootstrap的作者的仓库地址git@github.com:twbs/bootstrap.git克隆，因为没有权限，你将不能推送修改。

Bootstrap的官方仓库twbs/bootstrap、你在GitHub上克隆的仓库my/bootstrap，以及你自己克隆到本地电脑的仓库，他们的关系就像下图显示的那样：

如果你想修复bootstrap的一个bug，或者新增一个功能，立刻就可以开始干活，干完后，往自己的仓库推送。

如果你希望bootstrap的官方库能接受你的修改，你就可以在GitHub上发起一个pull request。当然，对方是否接受你的pull request就不一定了。

如果你没能力修改bootstrap，但又想要试一把pull request，那就Fork一下我的仓库：https://github.com/triaquae/gitskills ，创建一个your-github-id.txt的文本文件，写点自己学习Git的心得，然后推送一个pull request给我，我会视心情而定是否接受。

小结

• 在GitHub上，可以任意Fork开源仓库；

• 自己拥有Fork后的仓库的读写权限；

• 可以推送pull request给官方仓库来贡献代码。

2.7、 忽略特殊文件.gitignore

有些时候，你必须把某些文件放到Git工作目录中，但又不能提交它们，比如保存了数据库密码的配置文件啦，等等，每次git status都会显示Untracked files ...，有强迫症的童鞋心里肯定不爽。

好在Git考虑到了大家的感受，这个问题解决起来也很简单，在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件。

不需要从头写.gitignore文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了。所有配置文件可以直接在线浏览：https://github.com/github/gitignore

忽略文件的原则是：

1. 忽略操作系统自动生成的文件，比如缩略图等；
2. 忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件；
3. 忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件。

举个例子：

假设你在Windows下进行Python开发，Windows会自动在有图片的目录下生成隐藏的缩略图文件，如果有自定义目录，目录下就会有Desktop.ini文件，因此你需要忽略Windows自动生成的垃圾文件：

1 2 3 4

# Windows: Thumbs.db ehthumbs.db Desktop.ini

然后，继续忽略Python编译产生的.pyc、.pyo、dist等文件或目录：

1 2 3 4 5 6 7

# Python: *.py[cod] *.so *.egg *.egg-info dist build

加上你自己定义的文件，最终得到一个完整的.gitignore文件，内容如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

# 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了。

有些时候，你想添加一个文件到Git，但发现添加不了，原因是这个文件被.gitignore忽略了：

1 2 3 4

$ git add App.class The following paths are ignored by one of your .gitignore files: App.class Use -f if you really want to add them.

如果你确实想添加该文件，可以用-f强制添加到Git：

1	$ git add -f App.class

或者你发现，可能是.gitignore写得有问题，需要找出来到底哪个规则写错了，可以用git check-ignore命令检查：

1 2	$ git check-ignore -v App.class .gitignore:3:*.class    App.class

Git会告诉我们，.gitignore的第3行规则忽略了该文件，于是我们就可以知道应该修订哪个规则。

小结

• 忽略某些文件时，需要编写.gitignore；

• .gitignore文件本身要放到版本库里，并且可以对.gitignore做版本管理！

2.8、基本操作小结

相信大家对Git的基本操作有一定的了解，下面进行一下简单的梳理总结：

1. 命令 git config --global user.name "name" #配置git使用用户
2. # git config --global user.email "mail" #配置git使用邮箱
3. # git config --global color.ui true #配置颜色
4. # git config --list #查看当前配置
5. # git init #初始为git工作目录
6. # git status #查看git状态
7. # git reflog #查看未来历史更新点
8. # git reset --hard 4bf5b29 #找到历史还原点的SHA-1值，就可以还原(值不写全,系统会自动匹配)
9. # git checkout -- file #恢复暂存区至上一版本
10. # git add [file1] [file2] ... #添加指定文件至暂存区
11. # git add [dir] #添加指定目录至暂存区,包括子目录(递归添加)
12. # git add . #添加当前目录所有文件至暂存区
13. # git rm [file1] [file2] ... #删除工作区文件,并将这次删除放入暂存区
14. # git rm –cached [file] #停止追踪指定文件，但该文件会保留在工作区
15. # git mv [file-old] [file-new] #重命名文件,修改后放入暂存区