Git使用教程_changes not staged for commit: (use "git add

git简介：

https://www.liaoxuefeng.com/wiki/896043488029600/896954074659008

1. Git：分布式版本控制系统，C语言开发的。
2. 版本控制系统：软件开发过程中各种程序代码、配置文件及说明文档等文件变更的管理，方便查看历史记录，备份以便恢复以前的版本，用于协调多人开发的软件工程技术。

---

集中式与分布式版本控制系统的区别：

3. 集中式版本控制系统(如svn)：版本库是集中存放在中央服务器的，而干活的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。
4. 集中式的缺点：必须联网才能工作，速度受网速影响，版本库都在中央服务器中，安全性差。
5. 分布式版本控制系统(如Git)：没有“中央服务器”，每个人的电脑上都是一个完整的版本库，工作的时候不需要联网。多人协作？比方说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。
6. 分布式如何互相推送修改文件：在实际使用中很少在两人之间的电脑上推送版本库的修改，因为可能不在一个局域网内电脑间互相访问不了。因此，分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。

安装git

windows下安装:

7. git下载网址：https://git-scm.com/downloads，并安装。
8. 什么是版本库呢？版本库又名仓库，英文名repository，里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。

创建版本库：

9. 选择合适的目录，通过右键git bash，创建空目录：

   $ mkdir learngit
   $ cd learngit
   $ pwd
   /d/apply/git_repository/learngit
   1
   2
   3
   4

10. 第二步，通过git init命令把该目录变成Git可以管理的仓库：

    $ git init
    Initialized empty Git repository in D:/apply/git_repository/learngit/.git/
    1
    2

现在Git就把仓库建好了，而且告诉你是一个空的仓库（empty Git repository），此时当前目录下多了一个.git的目录，这个目录是Git来跟踪管理版本库的，没事千万不要手动修改这个目录里面的文件，不然改乱了，就把Git仓库给破坏了。

文件添加到版本库

11. 注意：所有的版本控制系统，其实只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等等，Git也不例外。版本控制系统可以告诉你每次的改动，比如在第5行加了一个单词“Linux”，在第8行删了一个单词“Windows”。而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道。
12. 不幸的是，Microsoft的Word格式是二进制格式，因此，版本控制系统是没法跟踪Word文件的改动的，前面我们举的例子只是为了演示，如果要真正使用版本控制系统，就要以纯文本方式编写文件。
13. 因为文本是有编码的，比如中文有常用的GBK编码，日文有Shift_JIS编码，如果没有历史遗留问题，强烈建议使用标准的UTF-8编码，所有语言使用同一种编码，既没有冲突，又被所有平台所支持。
14. 千万不要使用Windows自带的记事本编辑任何文本文件。原因是Microsoft开发记事本的团队使用了一个非常弱智的行为来保存UTF-8编码的文件，他们自作聪明地在每个文件开头添加了0xefbbbf（十六进制）的字符，你会遇到很多不可思议的问题，比如，网页第一行可能会显示一个“?”，明明正确的程序一编译就报语法错误，等等，都是由记事本的弱智行为带来的。建议你下载Notepad++代替记事本，不但功能强大，而且免费！记得把Notepad++的默认编码设置为UTF-8 without BOM即可：

	1. 编写一个readme.txt文件，内容随意,一定要放到learngit目录下（子目录也行），因为
	   这是一个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 commit命令执行成功后会告诉
	你，1 file changed被改动（我们新添加的readme.txt文件）;2 insertions: 插入了两
	行内容（readme.txt有两行内容）。
1
2
3
4
5
6
7
8
9
10
11
12
13

查询历史

查询历史状态

1. git status命令：了解工作区的状态。

-- 修改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

no changes added to commit (use "git add" and/or "git commit -a")
1
2
3
4
5
6
7
8
9
10

2. git diff命令：如果git status告诉你有文件被修改过，则使用该命令查看修改内容。

-- git status显示有改变，此时使用git diff查看具体修改内容
$ git diff readme.txt 
diff --git a/readme.txt b/readme.txt
index 46d49bf..9247db6 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,2 +1,2 @@
-Git is a version control system.
+Git is a distributed version control system.
 Git is free software
1
2
3
4
5
6
7
8
9
10

版本回退

1. Git中每当你觉得文件修改到一定程度的时候，就可以“保存一个快照”，这个快照在Git中被称为commit。

2. git reset --hard commit_id命令：HEAD指向的版本就是当前版本，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id可以回退到指定版本号。

$ git reset --hard 7aa2101
HEAD is now at 7aa2101 append GPL
1
2

3. git log命令：显示从最近到最远的提交日志，可以查看提交历史，以便确定要回退到哪个版本，如果嫌输出信息太多，看得眼花缭乱的，可以试试加上–pretty=oneline参数。

$ git log
commit 7aa21019fb04b86cdac8d4d22d5ca80b22125786
Author: LIGHT OF HOPE <1176041859@qq.com>
Date:   Wed Aug 5 10:02:34 2020 +0800

    append GPL

commit e1510a1404a3d306532d05d2be1eb6027cf2c418
Author: LIGHT OF HOPE <1176041859@qq.com>
Date:   Wed Aug 5 09:16:43 2020 +0800

    add distributed

commit 4fbcb2e36d3da92b906708431f404afccf60cb2a
Author: LIGHT OF HOPE <1176041859@qq.com>
Date:   Mon Aug 3 22:00:05 2020 +0800

    wrote a readme file
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

4. git reflog命令：回退到某个历史版本后如果再使用git log命令，无法查看到该历史版本之前的未来版本，git reflog命令可以记录运行过的每一条命令，此时可以找到未来的某个版本版本。

$ git reflog
7aa2101 HEAD@{0}: reset: moving to 7aa2101
e1510a1 HEAD@{1}: reset: moving to HEAD^
7aa2101 HEAD@{2}: commit: append GPL
e1510a1 HEAD@{3}: commit: add distributed
4fbcb2e HEAD@{4}: commit (initial): wrote a readme file
1
2
3
4
5
6

工作区和暂存区

1. 工作区（Working Directory）：就是你在电脑里能看到的目录，比如我的learngit（git仓库）文件夹就是一个工作区。

2. 版本库（Repository）：工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库，Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
   

3. 把文件往Git版本库里添加的时候，是分两步执行的：
   （a）第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；
   （b）第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。

管理修改

1. Git跟踪并管理的是修改，而非文件。
2. git diff HEAD – readme.txt（指定文件）：查看指定文件在工作区和版本库里面最新版本的区别。

$ git diff HEAD -- readme.txt 
diff --git a/readme.txt b/readme.txt
index 76d770f..a9c5755 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,4 +1,4 @@
 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.
+Git tracks changes of files.
1
2
3
4
5
6
7
8
9
10
11

撤销修改

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

$ 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
1
2
3
4
5
6
7
8
9

注意：git checkout – file命令中的 --很重要，没有 --，就变成了“切换到另一个分支”的命令，我们在后面的分支管理中会再次遇到git checkout命令。

场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD < file>（指定文件），就回到了场景1，第二步按场景1操作。

-- 第一步
$ git reset HEAD readme.txt
Unstaged changes after reset:
M       readme.txt
-- 第二步
$ git checkout -- readme.txt

1
2
3
4
5
6
7

场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。

注意：git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本。

删除文件

1. rm命令：通常直接在文件管理器中把没用的文件删了，或者使用rm命令删了。

 rm test.txt（文件名）
1

这个时候，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
1
2
3
4
5
6
7

此时有两种选择：
（1）如果确定删除版本库中的文件，则使用命令git rm删掉，并且git commit：

-- 删除版本库中的文件
$ git rm test.txt
rm 'test.txt'

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

1
2
3
4
5
6
7
8
9

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

$ git reset HEAD test.txt
Unstaged changes after reset:
D       test.txt

$ git checkout -- test.txt
1
2
3
4
5

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

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

远程仓库

• Git是分布式版本控制系统，同一个Git仓库，可以分布到不同的机器上。怎么分布呢？最早，肯定只有一台机器有一个原始版本库，此后，别的机器可以“克隆”这个原始版本库，而且每台机器的版本库其实都是一样的，并没有主次之分。
• 完全可以自己搭建一台运行Git的服务器，不过有GitHub这个神奇的网站，从名字就可以看出，这个网站就是提供Git仓库托管服务的，所以，只要注册一个GitHub账号，就可以免费获得Git远程仓库。
• 由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的，所以，需要一点设置：
  • 第1步：创建SSH Key。在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：
  • 第2步：登陆GitHub，打开“Account settings”，“SSH Keys”页面，然后，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容：
  • 为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。

-- 生成ssh key
ssh-keygen -t rsa -C "youremail@example.com"
1
2

添加远程库

• 现在的情景是，你已经在本地创建了一个Git仓库后，又想在GitHub创建一个Git仓库，并且让这两个仓库进行远程同步，这样，GitHub上的仓库既可以作为备份，又可以让其他人通过该仓库来协作，真是一举多得。
  （1）首先，登陆GitHub，然后，在右上角找到“Create a new repo”按钮，创建一个新的仓库。
  （2）在Repository name填入仓库名，其他保持默认设置，点击“Create repository”按钮，就成功地创建了一个新的Git仓库。
  
  目前，在GitHub上的这个learngit仓库还是空的，GitHub告诉我们，可以从这个仓库克隆出新的仓库，也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitHub仓库。
  
• 将存在的仓库推送到git仓库：

-- 后面为指定git仓库的url地址
$ git remote add origin https://github.com/cshai-github/learngit.git

-- 推送到origin远程库，下面报错是因为需要登陆git账目密码
$ git push -u origin master
Fatal: HttpRequestException encountered.
Username for 'https://github.com': 1176041859@qq.com
Counting objects: 16, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (16/16), 1.36 KiB | 0 bytes/s, done.
Total 16 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), done.
To https://github.com/cshai-github/learngit.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

注意：添加后，远程库的名字就是origin，这是Git默认的叫法（如上述图片中显示的命令），也可以改成别的，但是origin这个名字一看就知道是远程库。

把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。
由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。

-- 第一次推送完后，以后的推送则可以简化命令
$ git push origin master
1
2

总结：

1. 要关联一个远程库，使用命令git remote add origin 相关git仓库的url；
2. 关联后，使用命令git push -u origin master第一次推送master分支的所有内容；此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；
3. 分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在，也就是有没有联网都可以正常工作，而SVN在没有联网的时候是拒绝干活的！当有网络的时候，再把本地提交推送一下就完成了同步，真是太方便了！

从远程库克隆

-- 在工作空间右键git bash运行如下命令
$ git clone git@github.com:cshai-github/csh_code.git
Cloning into 'csh_code'...
remote: Enumerating objects: 16, done.
remote: Counting objects: 100% (16/16), done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 16 (delta 1), reused 3 (delta 0), pack-reused 0
Receiving objects: 100% (16/16), 4.25 KiB | 0 bytes/s, done.
Resolving deltas: 100% (1/1), done.
Checking connectivity... done.
1
2
3
4
5
6
7
8
9
10

小结

• 要克隆一个仓库，首先必须知道仓库的地址，然后使用git clone命令克隆。
• Git支持多种协议，包括https，但ssh协议速度最快。

分支管理

分支：类似于平行宇宙，当你正在电脑前努力学习Git的时候，另一个你正在另一个平行宇宙里努力学习SVN。如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，结果，你既学会了Git又学会了SVN！

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

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

SVN与Git分支管理的区别： 其他版本控制系统如SVN等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分支比蜗牛还慢，简直让人无法忍受，结果分支功能成了摆设，大家都不去用。
但Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是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分支：
  

Git鼓励大量使用分支，相关命令如下：

查看分支：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>

（1）查看所有分支
$ git branch
 * master
（2）创建dev分支
$ git branch dev
（3）再次查看所有分支
$ git branch
  dev
 * master
（4）第四步使用git switch报错，所有此处使用有相同功能的
$ git switch dev
git: 'switch' is not a git command. See 'git --help'.
（5）此时查看分支，（4）命令无效
$ git branch
  dev
 * master
（6）切换到dev分支
$ git checkout dev
Switched to branch 'dev'
（7）
$ git branch
 * dev
  master
（8）修改test.txt文件并添加到暂存区
$ git add test.txt
（9）提交暂存区的内容
$ git commit -m "add numer in test.txt"
[dev 239e11a] add numer in test.txt
 1 file changed, 1 insertion(+)
（10）切换回master分支
$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
（11）查看本地仓库test.txt文件发现没有dev分支上修改的内容或者不存在test.txt文件
$ git branch
  dev
 * master
（12）将dev分支合并到当前分支master上，并查看本地仓库在test.txt文件，发现与dev分支内容一致
$ git merge dev
Updating 93aaed6..239e11a
Fast-forward
 test.txt | 1 +
 1 file changed, 1 insertion(+)
（13）删除dev分支
$ git branch -d dev
Deleted branch dev (was 239e11a).
（14）
$ git branch
 * master
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

注意： 到切换分支使用git checkout < branch>，而前面讲过的撤销修改则是git checkout – < file>，同一个命令，有两种作用，确实有点令人迷惑。
实际上，切换分支这个动作，用switch更科学。因此，最新版本的Git提供了新的git switch命令来切换分支。

解决冲突

• 当各自分支修改了相同文件并都进行了提交，当进行合并的时候会出现冲突。
  

-- 此时进行合并时会报类似的错误
$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.

查看文件如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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

• Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容。
• 此时我们修改内容并重新添加提交，分支会变成如下形式：
  
• 通过git log --graph --pretty=oneline命令查看分支图：

$ 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
1
2
3
4
5
6
7
8
9
10
11
12
13
14

• 最后删除其他分支，只保留主分支master。

小结

• 当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
• 解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。
• 用 git log --graph 命令可以看到分支合并图。

分支管理策略

• 通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息，此时使用 git log --graph --pretty=oneline 命令看不到分支情况。
• 如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
  

分支策略

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

• 首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
• 那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
• 你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

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

小结

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

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
1
2
3
4
5
6
7
8
9
10
11
12

• 并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？
• 幸好，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge
1
2

• 现在，用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'
1
2
3
4
5
6
7

• 现在修复bug，然后提交：

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

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

 git switch 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 "merged bug fix 101" issue-101
Merge made by the 'recursive' strategy.
 readme.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
1
2
3
4
5
6
7
8
9

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

$ git switch dev
Switched to branch 'dev'

$ git status
On branch dev
nothing to commit, working tree clean
1
2
3
4
5
6

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

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

• 工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：
  一是用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} (5d677e2ee266f39ea296182fb2354265b91b3b2a)
1
2
3
4
5
6
7
8
9
10
11
12
13
14

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

$ git stash list
1

• 在master分支上修复了bug后，我们要想一想，dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。
  那怎么在dev分支上修复同样的bug？重复操作一次，提交不就行了？
  有木有更简单的方法？
  有！
  同样的bug，要在dev上修复，我们只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。注意：我们只想复制4c805e2 fix bug 101这个提交所做的修改，并不是把整个master分支merge过来。
• 为了方便操作，Git专门提供了一个 cherry-pick ，让我们能复制一个特定的提交到当前分支：

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

小结

• 修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
• 当手头工作没有完成时，先把工作现场 git stash 一下，然后去修复bug，修复后，再 git stash pop，回到工作现场；
• 在master分支上修复的bug，想要合并到当前dev分支，可以用 git cherry-pick < commit>（指定提交的id） 命令，把bug提交的修改“复制”到当前分支，避免重复劳动。

Feature分支

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

多人协作

• 查看远程库信息，使用git remote -v；
• 本地新建的分支如果不推送到远程，对其他人就是不可见的；
• 从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交，如果git pull失败，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接，使用git branch --set-upstream branch-name origin/branch-name命令；
• 在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；
• 建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；
• 从远程抓取分支，使用git pull，如果有冲突，要先处理冲突，然后再push。

rebase

• 多人在同一个分支上协作时，很容易出现冲突。即使没有冲突，后push的童鞋不得不先pull，在本地合并，然后才能push成功，每次合并再push后分支会不断交叉，看起来很不直观，因此git pull完后，使用 git rebase 命令，然后再git push，此时git log --graph查看历史就会变成直线。

小结

• rebase操作可以把本地未push的分叉提交历史整理成直线；
• rebase的目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比。

标签管理

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

Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的。

Git有commit，为什么还要引入tag？

“请把上周一的那个版本打包发布，commit号是6a5819e…”

“一串乱七八糟的数字不好找！”

如果换一个办法：

“请把上周一的那个版本打包发布，版本号是v1.2”

“好的，按照tag v1.2查找commit就行！”

所以，tag就是一个让人容易记住的有意义的名字，它跟某个commit绑在一起。

创建标签

• 在Git中打标签非常简单，首先，切换到需要打标签的分支上：

$ git branch
 * dev
  master
$ git checkout master
Switched to branch 'master'
1
2
3
4
5

• 然后，敲命令git tag 就可以打一个新标签：

$ git tag v1.0
1

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

$ git tag
v1.0
1
2

• 默认标签是打在最新提交的commit上的。有时候，如果忘了打标签，比如，现在已经是周五了，但应该在周一打的标签没有打，怎么办？
  方法是找到历史提交的commit id，然后打上就可以了：

$ git log --pretty=oneline --abbrev-commit
12a631b (HEAD -> master, tag: v1.0, origin/master) merged bug fix 101
4c805e2 fix bug 101
e1e9c68 merge with no-ff
f52c633 add merge
cf810e4 conflict fixed
5dc6824 & simple
14096d0 AND simple
b17d20e branch test
d46f35e 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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

• 比方说要对add merge这次提交打标签，它对应的commit id是f52c633，敲入命令：

$ git tag v0.9 f52c633
1

• 再用命令git tag查看标签：

$ git tag
v0.9
v1.0
1
2
3

• 注意，标签不是按时间顺序列出，而是按字母排序的。可以用git show 查看标签信息：

$ git show v0.9
commit f52c63349bc3c1593499807e5c8e972b82c8f286 (tag: v0.9)
Author: Michael Liao <askxuefeng@gmail.com>
Date:   Fri May 18 21:56:54 2018 +0800

    add merge

diff --git a/readme.txt b/readme.txt
...
1
2
3
4
5
6
7
8
9

• 可以看到，v0.9确实打在add merge这次提交上。
  还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字：

$ git tag -a v0.1 -m "version 0.1 released" 1094adb
1

小结

• 命令git tag 用于新建一个标签，默认为HEAD，也可以指定一个commit id；
• 命令git tag -a -m "blablabla…"可以指定标签信息；
• 命令git tag可以查看所有标签。

操作标签

• 如果标签打错了，也可以删除：

$ git tag -d v0.1
Deleted tag 'v0.1' (was f15b0dd)
1
2

• 因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。
• 如果要推送某个标签到远程，使用命令git push origin ：

$ git push origin v1.0
Total 0 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git
 * [new tag]         v1.0 -> v1.0
1
2
3
4

• 或者，一次性推送全部尚未推送到远程的本地标签：

$ git push origin --tags
Total 0 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git
 * [new tag]         v0.9 -> v0.9
1
2
3
4

• 如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除：

$ git tag -d v0.9
Deleted tag 'v0.9' (was f52c633)
1
2

• 然后，从远程删除。删除命令也是push，但是格式如下：

$ git push origin :refs/tags/v0.9
To github.com:michaelliao/learngit.git
 - [deleted]         v0.9
1
2
3

小结

• 命令git push origin < tagname>可以推送一个本地标签；
• 命令git push origin --tags可以推送全部未推送过的本地标签；
• 命令git tag -d < tagname>可以删除一个本地标签；
• 命令git push origin :refs/tags/< tagname>可以删除一个远程标签。

拉区代码报错：git报错fatal: unable to access ‘https://github.com/…‘: OpenSSL SSL_read: Connection was reset, e
解决办法，解除ssl：git config --global http.sslVerify “false”