Git学习笔记

本博客整理自廖雪峰Git教程和Git菜鸟教程

---

1. 安装Git

1.1. 在Linux上安装Git

首先可以试着输入git，看系统有没有安装Git：

$ git
The program 'git' is currently not installed. You can install it by typing:
sudo apt-get install git

Debian/Ubuntu Git 安装命令为：

$ sudo apt-get install git

$ git --version
git version 2.32.0

1.2. 在Windows上安装Git

在Windows上使用Git，可以从Git官网直接下载安装程序，然后按默认选项安装即可。

安装完成后，在开始菜单里找到“Git”->“Git Bash”，蹦出一个类似命令行窗口的东西，就说明Git安装成功。

1.3. Git 配置

1.3.1. 配置用户信息

配置个人的用户名称和电子邮件地址：

$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"

因为Git是分布式版本控制系统，所以，每个机器都必须自报家门：你的名字和Email地址。

注意git config命令的--global参数，用了这个参数，表示你这台机器上所有的Git仓库都会使用这个配置。
如果要在某个特定的Git仓库中使用其他名字或者电邮，只要去掉 --global 选项重新配置即可，新的设定保存在当前项目的 .git/config 文件里。

1.3.2. 文本编辑器

设置Git默认使用的文本编辑器, 一般是 Vi 或者 Vim：

$ git config --global core.editor vim

1.3.3. 查看配置信息

要检查已有的配置信息，可以使用 git config --list 命令

2. Git 基本操作

2.1. 创建版本库

版本库又名仓库，英文名repository，你可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。

1.选择一个合适的地方，创建一个空目录：

$ mkdir learngit
$ cd learngit
$ pwd
/Users/michael/learngit

2.通过git init命令把这个目录变成Git可以管理的仓库：

$ git init
Initialized empty Git repository in /Users/michael/learngit/.git/

创建完成之后当前目录下会多一个.git目录，这个目录是Git用来跟踪管理版本库的，不要随意修改目录里面的文件。
.git目录默认是隐藏的，用ls -ah命令就可以看见

2.2. 添加文件到版本库

1.编写一个readme.txt文件，内容如下：

Git is a version control system.
Git is free software.

readme.txt文件一定要放到learngit目录下，因为这是一个Git仓库，放到其他地方Git找不到这个文件

2.用命令git add告诉Git，把文件添加到仓库：

$ git add readme.txt

3.用命令git commit告诉Git，把文件提交到仓库：

$ git commit -m "wrote a readme file"
[master (root-commit) eaadf4e] wrote a readme file
 1 file changed, 2 insertions(+)
 create mode 100644 readme.txt

git commit命令，-m后面输入的是本次提交的说明，可以输入任意内容，这样你就能从历史记录里方便地找到改动记录

总结：

• 初始化一个Git仓库，使用git init命令。
• 添加文件到Git仓库，分两步:

1. 使用命令git add <file> 添加文件到暂存区，注意，可反复多次使用，添加多个文件；
2. 使用命令git commit -m <message>，将暂存区内容添加到仓库中。

• 要随时掌握工作区的状态，使用git status命令。

• 如果git status告诉你有文件被修改过，用git diff可以查看修改内容

2.3. 版本回退

2.3.1. 查看历史提交日志

1.修改readme.txt文件，改成如下内容：

Git is a distributed version control system.
Git is free software.

将改动添加到到暂存区：

$ git add readme.txt

提交暂存区到本地仓库

$ git commit -m "add distributed"
[master e475afc] add distributed
 1 file changed, 1 insertion(+), 1 deletion(-)

2.继续修改文件，改成如下内容：

Git is a distributed version control system.
Git is free software distributed under the GPL.

然后尝试提交：

$ git add readme.txt
$ git commit -m "append GPL"
[master 1094adb] append GPL
 1 file changed, 1 insertion(+), 1 deletion(-)

每当你觉得文件修改到一定程度的时候，就可以“保存一个快照”，这个快照在Git中被称为commit。一旦你把文件改乱了或者误删了文件，还可以从最近的一个commit恢复，然后继续工作，不至于丢失工作成果

3.用git log命令查看历史提交记录：

$ git log
commit 1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master)
Author: Michael Liao <askxuefeng@gmail.com>
Date:   Fri May 18 21:06:15 2018 +0800

    append GPL

commit e475afc93c209a690c39c13a46716e8fa000c366
Author: Michael Liao <askxuefeng@gmail.com>
Date:   Fri May 18 21:03:36 2018 +0800

    add distributed

commit eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0
Author: Michael Liao <askxuefeng@gmail.com>
Date:   Fri May 18 20:59:18 2018 +0800

    wrote a readme file

git log命令显示从最近到最远的提交日志，我们可以看到3次提交，最近的一次是append GPL，然后是add distributed，最早的一次是wrote a readme file

2.3.2. 回退到特定版本

在Git中用HEAD表示当前版本，也就是最新的提交1094adb...，上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100

把当前版本append GPL回退到上一个版本add distributed，可以使用git reset命令：

$ git reset --hard HEAD^
HEAD is now at e475afc add distributed

用cat查看readme.txt的内容，版本已经是add distributed：

$ cat readme.txt
Git is a distributed version control system.
Git is free software.

想再回到append GPL这个未来的版本，需要找到的append GPL版本的commit id 1094adb...：

$ git reset --hard 1094a
HEAD is now at 83b0afe append GPL

再查看，果然还原回来了

$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.

在Git当你用git reset --hard HEAD^回退到add distributed版本时，再想恢复到append GPL，就必须找到append GPL的commit id。Git提供了一个命令git reflog用来记录你的每一次命令：

$ git reflog
e475afc HEAD@{1}: reset: moving to HEAD^
1094adb (HEAD -> master) HEAD@{2}: commit: append GPL
e475afc HEAD@{3}: commit: add distributed
eaadf4e HEAD@{4}: commit (initial): wrote a readme file

从输出可知，append GPL的commit id是1094adb，现在你可以通过git reset --hard 1094a回退到append GPL版本

---

Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把HEAD从指向append GPL：

改为指向add distributed：

然后顺便把工作区的文件更新了。所以你让HEAD指向哪个版本号，你就把当前版本定位在哪。

---

总结：

• HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。

• 穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。

• 要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。

2.4. Git 工作区、暂存区和版本库

• 工作区：就是你在电脑里能看到的目录，比如learngit文件夹就是一个工作区
• 暂存区：英文叫 stage 或 index。一般存放在.git目录下的 index 文件（.git/index）中，所以我们把暂存区有时也叫作索引（index）。
• 版本库：工作区有一个隐藏目录 .git，这个不算工作区，而是 Git 的版本库。Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

• git add实际上就是把工作区的文件修改添加到暂存区

• git commit实际上就是把暂存区的所有内容提交到当前分支

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

来练习一遍，先对readme.txt做个修改，比如加上一行内容：

Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.

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

先用git status查看一下状态：

$ 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:   readme.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	LICENSE

no changes added to commit (use "git add" and/or "git commit -a")

可以知道readme.txt被修改了，而LICENSE还从来没有被添加过，所以它的状态是Untracked。

使用两次命令git add把readme.txt和LICENSE都添加后，再用git status查看一下：

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	new file:   LICENSE
	modified:   readme.txt

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

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

$ git commit -m "understand how stage works"
[master e43a48b] understand how stage works
 2 files changed, 2 insertions(+)
 create mode 100644 LICENSE

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

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

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

2.5. 撤销修改

2.5.1. 更改还未add到暂存区

假如你在readme.txt中添加了一行：

$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
My stupid boss still prefers SVN.

但是在你准备提交到暂存区前，你发现了错误想放弃更改，把文件恢复到上一个版本的状态，如果用git status查看一下：

$ 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:   readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

Git会告诉你，git checkout -- file可以丢弃工作区的修改：

$ git checkout -- readme.txt

命令git checkout -- readme.txt意思就是把readme.txt文件在工作区的修改全部撤销，这里有两种情况：

1. readme.txt自修改后还没有被放到暂存区，那么撤销修改就回到和版本库一模一样的状态；

2. readme.txt在添加到暂存区后又作了修改，那么撤销修改就回到添加到暂存区后的状态。

• 总之就是让这个文件回到最近一次git commit或git add时的状态。
• git checkout -- file命令中的--很重要，如果没有--就变成了“切换到另一个分支”的命令
• git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。

现在看看readme.txt的文件内容，文件内容已经被还原了：

$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.

2.5.2. 更改已经add到暂存区

如果错误更改已经git add提交到暂存区了：

$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
My stupid boss still prefers SVN.

$ git add readme.txt

在commit之前，你发现了这个问题想撤销修改。用git status查看一下，修改只是添加到了暂存区，还没有提交：

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	modified:   readme.txt

Git告诉我们，用命令git reset HEAD <file>可以把暂存区的修改撤销掉（unstage），重新放回工作区：

$ git reset HEAD readme.txt
Unstaged changes after reset:
M	readme.txt

再用git status查看一下，现在暂存区是干净的，工作区有修改：

$ 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:   readme.txt

最后再丢弃工作区的修改，方法之前提到过：

$ git checkout -- readme.txt

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

2.5.3. 更改已经提交到版本库

假设你不但改错了东西，还从暂存区提交到了版本库，那么只能使用git reset --hard commit_id回退到之前的版本，详细用法参考版本回退小节

git reset用法：

git reset 命令用于回退版本，可以指定退回某一次提交的版本。

• 不带参数时用于重置暂存区的文件与上一次的提交(commit)保持一致，工作区文件内容保持不变。

$ git reset HEAD^            # 回退所有内容到上一个版本  
$ git reset HEAD^ hello.php  # 回退 hello.php 文件的版本到上一个版本  
$ git  reset  052e           # 回退到指定版本052e

• 带--hard 参数时用于撤销工作区中所有未提交的修改内容，将暂存区与工作区都回到上一次版本，并删除之前的所有信息提交：

$ git reset –hard HEAD~3  # 回退上上上一个版本  
$ git reset –hard bae128  # 回退到某个版本回退点之前的所有信息。 
$ git reset --hard origin/master    # 将本地的状态回退到和远程的一样 

总结：

场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- file

场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步：

1. 用命令git reset HEAD ，就回到了场景1
2. 按场景1操作，用命令git checkout -- file再丢弃工作区修改

场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，使用git reset --hard commit_id回退到之前的版本

2.6. 删除文件

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

$ git add test.txt

$ git commit -m "add test.txt"
[master b84166e] add test.txt
 1 file changed, 1 insertion(+)
 create mode 100644 test.txt

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

$ rm test.txt

这个时候Git知道你删除了文件，工作区和版本库就不一致了，git status命令会立刻告诉你哪些文件被删除了：

$ git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	deleted:    test.txt

no changes added to commit (use "git add" and/or "git commit -a")

如果你确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit，这样文件就从版本库中被删除了：

$ git rm test.txt
rm 'test.txt'

$ git commit -m "remove test.txt"
[master d46f35e] remove test.txt
 1 file changed, 1 deletion(-)
 delete mode 100644 test.txt

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

$ git checkout -- test.txt

总结：

命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。

3. 远程仓库GitHub

3.1. 创建SSH key

1. 首先在GitHub注册一个账号：
   GitHub网站就是提供Git仓库托管服务的，所以只要注册一个GitHub账号，就可以免费获得Git远程仓库：GitHub link

2. 创建SSH Key：
   由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的，所以需要创建SSH key。打开Shell（Windows下打开Git Bash），创建SSH Key：

$ ssh-keygen -t rsa -C "youremail@example.com"

你需要把邮件地址换成你自己的邮件地址，然后一路回车，使用默认值即可，这个Key无需设置密码。

如果一切顺利的话，可以在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对

3. 登陆GitHub，打开“Settings”，“SSH and GPG Keys”页面：

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

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

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

3.2. 添加远程库

现在你已经在本地创建了一个Git仓库后，又想在GitHub创建一个Git仓库，并且让这两个仓库进行远程同步，这样，GitHub上的仓库既可以作为备份，又可以让其他人通过该仓库来协作。

首先，登陆GitHub，然后，在右上角找到“new repository”按钮，创建一个新的仓库:

在Repository name填入learngit，其他保持默认设置，点击“Create repository”按钮，就成功地创建了一个新的Git仓库：

目前在GitHub上的这个learngit仓库还是空的，我们可以从这个仓库克隆出新的仓库，也可以把一个已有的本地仓库与之关联，然后把本地仓库的内容推送到GitHub仓库。

在本地的learngit仓库下运行命令：

$ git remote add origin git@github.com:Evelynnuu/learngit.git

请注意，上面的Evelynnuu表示自己的GitHub账户名

添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。

下一步，就可以把本地库的所有内容推送到远程库上：

$ git push -u origin master
Counting objects: 20, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (20/20), 1.64 KiB | 560.00 KiB/s, done.
Total 20 (delta 5), reused 0 (delta 0)
remote: Resolving deltas: 100% (5/5), done.
To github.com:michaelliao/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分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。

推送成功后，可以立刻在GitHub页面中看到远程库的内容已经和本地一模一样：

从现在起，只要本地作了提交，就可以通过命令：

$ git push origin master

把本地master分支的最新修改推送至GitHub，现在，你就拥有了真正的分布式版本库！

3.3. 删除远程库

如果添加的时候地址写错了，或者就是想删除远程库，可以用git remote rm <name>命令。使用前，建议先用git remote -v查看远程库信息：

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

然后，根据名字删除，比如删除origin：

$ git remote rm origin

此处的“删除”其实是解除了本地和远程的绑定关系，并不是物理上删除了远程库。远程库本身并没有任何改动。要真正删除远程库，需要登录到GitHub，在后台页面找到删除按钮再删除。

总结：

• 要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git；

• 关联一个远程库时必须给远程库指定一个名字，origin是默认习惯命名；

• 关联后，使用命令git push -u origin master第一次推送master分支的所有内容；

• 此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改。

3.4. 从远程库克隆

首先登陆GitHub，创建一个新的仓库，名字叫gitskills：

我们勾选Add a README file，这样GitHub会自动为我们创建一个README.md文件。创建完毕后，可以看到README.md文件：

现在，远程库已经准备好了，下一步是用命令git clone克隆一个本地库：

$ git clone git@github.com:Evelynnuu/gitskills.git
Cloning into 'gitskills'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 3
Receiving objects: 100% (3/3), done.

注意把Git库的地址换成你自己的，然后进入gitskills目录看看，已经有README.md文件了：

$ cd gitskills
$ ls
README.md

GitHub还可以用https://github.com/username/gitskills.git这样的地址。实际上Git支持多种协议，默认的git://使用ssh，但也可以使用https等其他协议。

使用https除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令.

总结：

• 要克隆一个仓库，首先必须知道仓库的地址，然后使用git clone命令克隆。

• Git支持多种协议，包括https，但ssh协议速度最快。

---

4. 分支管理

4.1. 创建与合并分支

在版本回退里已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向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 / git switch -c dev
Switched to a new branch 'dev'

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

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

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

$ git branch
* dev
  master

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

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

Creating a new branch is quick.

然后提交：

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

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

$ git checkout master
Switched to branch 'master'

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

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

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

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

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

$ git branch -d dev
Deleted branch dev (was b17d20e).

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

$ git branch
* master

---

实际上，切换分支这个动作还可以用git switch来实现，创建并切换到新的dev分支，可以使用：

$ git switch -c dev

直接切换到已有的master分支，可以使用：

$ git switch master

使用新的git switch命令，比git checkout要更容易理解。

总结：

• 查看分支：git branch

• 创建分支：git branch <name>

• 切换分支：git checkout <name>或者git switch <name>

• 创建+切换分支：git checkout -b <name>或者git switch -c <name>

• 合并某分支到当前分支：git merge <name>

• 删除分支：git branch -d <name>

4.2. 解决合并冲突

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

$ git switch -c feature1
Switched to a new branch 'feature1'

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

Creating a new branch is quick AND simple.

在feature1分支上提交：

$ git add readme.txt

$ git commit -m "AND simple"
[feature1 14096d0] AND simple
 1 file changed, 1 insertion(+), 1 deletion(-)

切换到master分支：

$ git switch master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

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

Creating a new branch is quick & simple.

提交：

$ git add readme.txt 
$ git commit -m "& simple"
[master 5dc6824] & 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")
  (use "git merge --abort" to abort the merge)

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 distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1

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

Creating a new branch is quick and simple.

再提交：

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

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

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

$ git log --graph --pretty=oneline --abbrev-commit
*   cf810e4 (HEAD -> master) conflict fixed
|\  
| * 14096d0 (feature1) AND simple
* | 5dc6824 & simple
|/  
* b17d20e branch test
* d46f35e (origin/master) remove test.txt
* b84166e add test.txt
* 519219b git tracks changes
* e43a48b understand how stage works
* 1094adb append GPL
* e475afc add distributed
* eaadf4e wrote a readme file

最后，删除feature1分支：

$ git branch -d feature1
Deleted branch feature1 (was 14096d0).

总结：

• Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。

• 解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。

• 用git log --graph命令可以看到分支合并图。

4.3. 分支管理

• 普通模式合并分支

通常合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

---

• git stash保存工作现场

Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，然后切换到别的分支工作，等别的分支工作完成后，再切换回来，恢复现场后继续工作

恢复之前的工作现场有两个办法：

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

2. 用git stash pop，恢复的同时把stash内容也删了

• cherry pick复制提交

Git专门提供了一个cherry-pick命令，让我们能复制一个特定的提交到当前分支

$ git branch
* dev
  master
$ git cherry-pick 4c805e2
[master 1d4b803] fix bug 101
 1 file changed, 1 insertion(+), 1 deletion(-)

Git自动给dev分支做了一次提交，注意这次提交的commit是1d4b803，它并不同于master的4c805e2，因为这两个commit只是改动相同，但确实是两个不同的commit。用git cherry-pick，我们就不需要在dev分支上手动再把修bug的过程重复一遍。

总结：

• 修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；

• 当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场；

• 在master分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick <commit>命令，把bug提交的修改“复制”到当前分支，避免重复劳动。

• 开发一个新feature，最好新建一个分支；如果要丢弃一个没有被合并过的分支，可以通过git branch -D <name>强行删除。

• 从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；

5. 标签管理

发布一个版本时，我们通常先在版本库中打一个标签（tag），这样就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。

5.1. 创建标签

• 命令git tag <tagname>用于新建一个标签，默认为HEAD，也可使用git tag <tagname> commit_id给指定commit id打标签；

• 命令git tag -a <tagname> -m "blablabla..."可以指定标签信息；

• 命令git tag可以查看所有标签。

5.2. 操作标签

• 命令git push origin <tagname>可以推送一个本地标签；

• 命令git push origin --tags可以推送全部未推送过的本地标签；

• 命令git tag -d <tagname>可以删除一个本地标签；

• 命令git push origin :refs/tags/<tagname>可以删除一个远程标签。

Git常用命令资料：Git Cheat Sheet