https://github.com/thrfur/learnGit

创建版本库

初始化仓库

进入本地仓库目录：cd D:\learnGit
通过git init（ git Initialize ）命令把这个目录变成 Git 可以管理的仓库。
```
   D:\learnGit>git init
   Initialized empty Git repository in D:/learnGit/.git/
```
瞬间 Git 就把仓库建好了，并且还提示你这是一个空的仓库。通过查看隐藏文件可以发现该仓库目录下多了一个 .git 的目录，这个目录是 Git 用来跟踪管理版本库的。

在该目录下新建readme.txt文件，内容如下：

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

提交文件到仓库

用命令git add <file>告诉Git，把文件添加到仓库：git add readme.txt
用git commit -m <message>命令告诉Git，把文件提交到仓库：
```
   D:\learnGit>git commit -m "wrote a readme file"
   [master (root-commit) 44edf9b] wrote a readme file
    1 file changed, 2 insertions(+)
    create mode 100644 readme.txt
```
-m参数后面的是本次提交的说明，可以输入任意内容。到此就已经添加并提交了一个readme.txt文件。

文件历史

提交修改过的文件

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

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

运行git status命令查看结果：

   D:\learnGit>git status
   On branch master
   Changes not staged for commit:
     (use "git add <file>..." to update what will be committed)
     (use "git restore <file>..." to discard changes in working directory)
           modified:   readme.txt
   
   no changes added to commit (use "git add" and/or "git commit -a")

git status命令可以让我们时刻掌握仓库当前的状态，上面的命令输出告诉我们，readme.txt被修改过了，但还没有准备提交修改。

使用git diff命令（git difference）查看修改历史：

   D:\learnGit>git diff
   diff --git a/readme.txt b/readme.txt
   index d8036c1..013b5bc 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.
   \ No newline at end of file

diff命令可以查阅文件的修改历史。

再次提交修改过的readme.txt文件至仓库，提交修改和提交新文件都需要git add和git commit命令。

   git add readme.txt

执行完add命令后，再查看下仓库的状态：(对比 add 之前和之后的状态)

add after：

     D:\learnGit>git status
     On branch master
     Changes to be committed:
       (use "git restore --staged <file>..." to unstage)
             modified:   readme.txt

add before：

     D:\learnGit>git status
     On branch master
     Changes not staged for commit:
       (use "git add <file>..." to update what will be committed)
       (use "git restore <file>..." to discard changes in working directory)
             modified:   readme.txt
     
     no changes added to commit (use "git add" and/or "git commit -a")

现在就可以提交修改过的readme.txt文件到仓库了。

   D:\learnGit>git commit -m "add distributed"
   [master e528da2] add distributed
    1 file changed, 1 insertion(+), 1 deletion(-)

此时再查看下仓库的状态：
```
   D:\learnGit>git status
   On branch master
   nothing to commit, working tree clean
```
显而易见，当前已没有修改文件待提交，且工作台是“干净”的。

版本回退

再修改readme.txt文件：
```
   Git is a distributed version control system.
   Git is free software distributed under the GPL.
```
然后尝试提交：
```
   D:\learnGit>git add readme.txt
   
   D:\learnGit>git commit -m "append GPL"
   [master 2d7ea27] append GPL
    1 file changed, 1 insertion(+), 1 deletion(-)
```
不断对文件进行修改，然后不断提交修改到版本库里，Git 都会保存好每一份修改的“快照”。这个快照在 Git 中被称为commit。如果在某天，不小心把文件内容弄糊涂了，或者误删了某个文件，那么就可以通过最近的一个commit恢复，然后继续工作。

到此，readme.txt文件一共有三个版本（commit）被提交到了 Git 仓库里。

wrote a readme file

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

add distributed

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

append GPL

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

当然，实际中是想不起来每次都改了什么内容。但是，可以用git log命令查看历史记录。

   D:\learnGit>git log
   commit 2d7ea27a6cd010124eb88f74bbd5b2737ca0ee66 (HEAD -> master)
   Author: thrfur <47554753+thrfur@users.noreply.github.com>
   Date:   Wed Oct 27 14:09:22 2021 +0800
   
       append GPL
   
   commit e528da2c6059d63b5d498ae54957b7ed15ac7a76
   Author: thrfur <47554753+thrfur@users.noreply.github.com>
   Date:   Wed Oct 27 13:58:10 2021 +0800
   
       add distributed
   
   commit 44edf9bf9160f680e2c009e01c0e6e6b604a5cf5
   Author: thrfur <47554753+thrfur@users.noreply.github.com>
   Date:   Wed Oct 27 13:35:19 2021 +0800
   
       wrote a readme file

git log命令显示从最近到最远的提交日志，即commit信息。从上面的日志可以看出，最近的一次修改提交是append GPL，最早的一次提交是wrote a readme file。

现在，尝试回退到add distributed版本，也就是第二个版本。

在Git中，用HEAD表示当前版本，也就是最近一次提交的版本，上一个版本就是HEAD^，上上个版本就是HEAD^^，第一百个版本呢？HEAD~100

现在，把当前版本append GPL回退到add distributed。使用git reset命令。

   D:\learnGit>git reset --hard "HEAD^"
   HEAD is now at e528da2 add distributed

注意：在Windows中输入git reset --hard HEAD^命令后，命令行窗口会紧接着换一行弹出 More? 信息：
D:\learnGit>git reset --hard HEAD^
More?
别急，这其实是因为在Windows中，默认的换行符是^，而不是\，因此这More? 的意思就是下一行是否需要再输入，而^符号被当作换行符而被 Git 忽略掉了。

解决方法有如下几种：
git reset --hard "HEAD^"   //加引号
git reset --hard HEAD^^  //多加一个^

git reset --hard HEAD~ 或者 git reset --hard HEAD~1  
//把^换成~，~ 后面的数字表示回退几次提交，默认是一次

现在看看readme.txt文件的内容是不是版本add distributed的内容。

在Windows中，查看文件内容使用type命令。在Unix-like系统中，使用cat命令。

   D:\learnGit>type readme.txt
   Git is a distributed version control system.
   Git is free software.

据此，可以得知readme.txt文件的确被还原了。

版本回退后的恢复

如果想取消回退怎么办？只要回退后的那个命令行窗口未被关闭，那么就可以找到比回退的版本更新的某个版本，根据commit id就可以从”远“版本跳回”近“版本。

查看下版本库的状态：

   D:\learnGit>git log
   commit e528da2c6059d63b5d498ae54957b7ed15ac7a76 (HEAD -> master)
   Author: thrfur <47554753+thrfur@users.noreply.github.com>
   Date:   Wed Oct 27 13:58:10 2021 +0800
   
       add distributed
   
   commit 44edf9bf9160f680e2c009e01c0e6e6b604a5cf5
   Author: thrfur <47554753+thrfur@users.noreply.github.com>
   Date:   Wed Oct 27 13:35:19 2021 +0800
   
       wrote a readme file

现在readme.txt文件处于三个commit当中的第二个commit版本中，如何还原到最新的那个版本？
```
   D:\learnGit>git reset --hard 2d7ea27
   HEAD is now at 2d7ea27 append GPL
   
   //2d7ea27为"append GPL"版本的commit id(前几位)
```
版本号没必要写全，前几位就可以了，Git会自动去找。当然也不能只写前一两位，因为 Git 可能会找到多个版本号，就无法确定是哪一个了。

此时再查看readme.txt文件的内容：

   D:\learnGit>type readme.txt
   Git is a distributed version control system.
   Git is free software distributed under the GPL.

果然，回退后，readme.txt又还原到回退前的状态了。

Git 的回退速度非常快，因为 Git 在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把HEAD从指向append GPL改为指向add distributed。然后顺便把工作区的文件更新了。所以你让HEAD指向哪个版本号，你就把当前版本定位在哪。

新的问题来了，如果回退后，命令行窗口关闭了怎么办？当然，仍有办法补救。使用git reflog命令用来记录Git的每一次命令：

   D:\learnGit>git reflog
   2d7ea27 (HEAD -> master) HEAD@{0}: reset: moving to 2d7ea27
   e528da2 HEAD@{1}: reset: moving to HEAD^
   2d7ea27 (HEAD -> master) HEAD@{2}: commit: append GPL
   e528da2 HEAD@{3}: commit: add distributed
   44edf9b HEAD@{4}: commit (initial): wrote a readme file

可以看到，2d7ea27即为append GPL的commit id，知道 id 后，那么就可以用 git reset命令回退或恢复。

工作区和暂存区

工作区即整个仓库目录，如learnGit文件夹内的文件和文件夹就是一个工作区。注意，.git目录不算工作区，而是 Git 的版本库。
版本库(Repository)，版本库里存了很多东西，其中最重要的就是被称为 stage（或者叫index）的暂存区，还有 Git 为我们自动创建的第一个分支master，以及指向master的一个指针HEAD.

git-repo

git add命令实际上就是把要提交的所有修改放在暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支。
一旦git commit后，如果没有对工作区内的文件内容做出任何修改，那么工作区就是”干净“的。
```
  D:\learnGit>git status
  On branch master
  nothing to commit, working tree clean
```
git commit后，所有修改都从暂存区提交到了分支中去，此时暂存区就没有任何内容了。

管理修改

往readme.txt文件里加一行内容：

   Git is a distributed version control system.
   Git is free software distributed under the GPL.
   Git tracks changes.   //new add

然后使用git add命令将该修改记录丢入暂存区：

   D:\learnGit>git add readme.txt

再查看下 Git 的状态：

   D:\learnGit>git status
   On branch master
   Changes to be committed:
     (use "git restore --staged <file>..." to unstage)
           modified:   readme.txt

再修改readme.txt文件，修改最后一行：

   Git is a distributed version control system.
   Git is free software distributed under the GPL.
   Git tracks changes of files.  //modified

此时，直接commit，不add：

   D:\learnGit>git commit -m "git tracks changes"
   [master 1b4d4d2] git tracks changes
    1 file changed, 2 insertions(+), 1 deletion(-)

提交后，再看看状态：

   D:\learnGit>git status
   On branch master
   Changes not staged for commit:
     (use "git add <file>..." to update what will be committed)
     (use "git restore <file>..." to discard changes in working directory)
           modified:   readme.txt
   
   no changes added to commit (use "git add" and/or "git commit -a")

可以看到，第二次的修改没有被提交，这是因为：

第一次修改 –> git add –> 第二次修改 –> git commit

这说明，Git 只负责提交已add到暂存区的修改，而不commit未add到暂存区的修改。

提交后，用git diff HEAD -- readme.txt命令可以查看工作区和版本去里面最新版本的区别：

   D:\learnGit>git diff HEAD -- readme.txt
   diff --git a/readme.txt b/readme.txt
   index 7f43121..a51649f 100644
   --- a/readme.txt
   +++ b/readme.txt
   @@ -1,3 +1,3 @@
    Git is a distributed version control system.
    Git is free software distributed under the GPL.
   -Git tracks changes.
   \ No newline at end of file
   +Git tracks changes of files.
   \ No newline at end of file

可见，第二次修改确实没有被提交。但是，查看readme.txt文件却仍然显示的是第二次修改后的内容，很多人想，不应该显示的是第一次修改的内容吗？其实，工作区和版本库的内容是不一致的，因为第二次的修改未成功提交到版本库，所以版本库里的内容实际上只是第一次修改的内容，而工作区的readme.txt文件却有第二次的修改记录，只是没有成功提交给版本库罢了。可以看如下操作：

   D:\learnGit>git reflog
   1b4d4d2 (HEAD -> master) HEAD@{0}: commit: git tracks changes
   2d7ea27 HEAD@{1}: reset: moving to 2d7ea27
   e528da2 HEAD@{2}: reset: moving to HEAD^
   2d7ea27 HEAD@{3}: commit: append GPL
   e528da2 HEAD@{4}: commit: add distributed
   44edf9b HEAD@{5}: commit (initial): wrote a readme file
   
   D:\learnGit>type readme.txt
   Git is a distributed version control system.
   Git is free software distributed under the GPL.
   Git tracks changes of files.
   
   D:\learnGit>git reset --hard HEAD
   HEAD is now at 1b4d4d2 git tracks changes
   
   D:\learnGit>type readme.txt
   Git is a distributed version control system.
   Git is free software distributed under the GPL.
   Git tracks changes.

上面的操作一共type了两次readme.txt的内容，第一次type是工作区修改了两次的内容，经过git reset后，工作区的readme.txt文件内容被版本库里只有一次修改记录的已存信息覆盖掉了，所以第二次type后，readme.txt还原为只修改了一次的样子。

撤销修改

假如在readme.txt末尾添加一行：Waiting delete，如下：
```
   D:\learnGit>type readme.txt
   Git is a distributed version control system.
   Git is free software distributed under the GPL.
   Git tracks changes.
   Waiting delete
```
此时，仅在工作区修改了readme.txt文件，而没有git add到暂存区。如果想撤销对readme.txt文件末尾的修改，即删除Waiting delete，该怎么办？
既然错误发现得很及时，就可以很容易地纠正它。你可以删掉最后一行，手动把文件恢复到上一个版本的状态。当然，也可以用git checkout -- <file>命令丢弃对工作区内的文件的修改。这里有两种情况：
- 一种是：readme.txt修改后还未放至暂存区，所以git checkout后就回到和版本库一模一样的状态；
另一种是：readme.txt已经添加至暂存区，且工作区内又做了新修改，那么git checkout后就回到添加到暂存区时的状态。

总之，git checkout能让这个文件回到最近一次git add或git commit时的状态。

那么，执行一下git checkout命令：
```
  D:\learnGit>git checkout -- readme.txt
```
执行成功后是没有任何显示的，此时再看看readme.txt文件有没有被撤销修改：
```
  D:\learnGit>type readme.txt
  Git is a distributed version control system.
  Git is free software distributed under the GPL.
  Git tracks changes.
```
很好，已经撤销了。
git checkout -- <file>中的--很重要，如果没有--，就变成了 ”切换到另一个分支“ 的命令。因此git checkout命令不仅仅是撤销修改那么简单。

删除或恢复文件

在 Git 中，删除也是一个修改操作。

举个例子，在工作区添加一个新文件testDel.txt并随便记录点内容，然后git add到暂存区并git commit到版本库。

   D:\learnGit>type testDel.txt
   testDel, waiting delete.
   
   D:\learnGit>git add testDel.txt
   
   D:\learnGit>git commit -m "add testDel.txt"
   [master 82a936b] add testDel.txt
    1 file changed, 1 insertion(+)
    create mode 100644 testDel.txt

一般情况下，要想删除某个文件，通常是直接在文件管理器中把没用的文件删除，或者直接用rm命令：rm testDel.txt。但是，虽然删除了工作区中的testDel.txt文件，但是已经提交到版本库中的与工作区却不一致了。git status命令会立刻显示有哪些文件被删除了：
```
   D:\learnGit>git status
   On branch master
   Changes not staged for commit:
     (use "git add/rm <file>..." to update what will be committed)
     (use "git restore <file>..." to discard changes in working directory)
           deleted:    testDel.txt
   
   no changes added to commit (use "git add" and/or "git commit -a")
```
此时有两个选择：
- 一种是：从版本库中也删除该文件，用命令git rm <file>删掉，并且git commit：
```
     D:\learnGit>git rm testDel.txt
     rm 'testDel.txt'
     
     D:\learnGit>git commit -m "remove testDel.txt"
     [master b8bd49e] remove testDel.txt
      1 file changed, 1 deletion(-)
      delete mode 100644 testDel.txt
```
  此时再查看下版本库的状态：
```
     D:\learnGit>git status
     On branch master
     nothing to commit, working tree clean
```
  干净了。
- 另一种是：误删了，想要把在工作区的文件恢复，那么可以使用git check -- <file>命令将其恢复：
```
     D:\learnGit>git checkout -- testDel.txt
```
  git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以 “一键还原”。

远程仓库

这里开始使用大名鼎鼎的 Github。

设置SSH

在用户主目录下(以用户名为名称的文件夹)，看看有没有.ssh目录，如果有，则可以跳过。如果没有，则打开Git Bash，创建SSH Key：
```
   $ ssh-keygen -t rsa -C "youremail@example.com"
```
将youremail@example.com替换为自己的邮件地址（随意填写常用的邮箱即可，没有限制必须填写Github的注册邮箱）。输入上述命令并回车后，一路按回车，使用默认值。完毕后，可以在用户根目录下找到.ssh目录，比如C:\Users\yourUserName\.ssh，这个目录里包含id_rsa和id_rsa.pub两个文件，其中id_rsa是私钥，绝对不能泄露，id_rsa.pub是公钥，可以放心地告诉任何人。
登录Github，打开“Account settings” –> ”SSH and GPG Keys“页面，然后点SSH Keys旁边的 ”New SSH Key“ ，填上任意Title，在文本框粘贴公钥id_rsa.pub文件地内容，然后点击 ”Add SSH Key“。

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

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

添加远程库

本地有一个仓库，Github上也有一个仓库，并且本地仓库和Github上的仓库是同步的，那么GitHub上的仓库既可以作为备份，又可以让其他人通过该仓库来协作，真是一举多得。

在Github上创建一个learnGit仓库（Repositories）。

创建出来的新仓库还是空的，Github会给出相应的命令让我们可以从本地或其它既有仓库中与之关联。这些默认命令为：

create a new repository on the command line

     echo "# learnGit" >> README.md
     git init
     git add README.md
     git commit -m "first commit"
     git branch -M main
     git remote add origin https://github.com/userName/learnGit.git
     git push -u origin main

push an existing repository from the command line

     git remote add origin https://github.com/userName/learnGit.git
     git branch -M main
     git push -u origin main

根据Github的提示，在本地的learnGit仓库下运行下述命令：
```
   git remote add origin https://github.com/userName/learnGit.git
```
添加后，远程库的名字就是origin，这是Git的默认叫法，也可以改成别的，但是origin一看就知道是远程库。

使用git push命令把本地仓库的所有内容都推送到远程仓库上，用git push命令。实际上是把当前分支master推送到远程。

   D:\learnGit>git push -u origin master
   Enumerating objects: 16, done.
   Counting objects: 100% (16/16), done.
   Delta compression using up to 6 threads
   Compressing objects: 100% (11/11), done.
   Writing objects: 100% (16/16), 1.41 KiB | 719.00 KiB/s, done.
   Total 16 (delta 3), reused 0 (delta 0), pack-reused 0
   remote: Resolving deltas: 100% (3/3), done.
   To https://github.com/thrfur/learnGit.git
    * [new branch]      master -> master
   Branch 'master' set up to track remote branch 'master' from 'origin'.

由于远程库是空的，第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送到远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令，比如以后只使用git push origin master命令推送最新修改到Github仓库里。

推送成功后，可以立刻在GitHub页面中看到远程库的内容已经和本地一模一样。从现在起，只要本地作了提交，就可以通过命令：
```
   git push origin master
```
把本地master分支的最新修改推送至GitHub。

删除远程库

使用git remote -v查看远程库信息：

   D:\learnGit>git remote -v
   origin  https://github.com/userName/learnGit.git (fetch)
   origin  https://github.com/userName/learnGit.git (push)

然后，使用git remote rm <name>命令，根据名字删除，比如删除origin：
```
   D:\learnGit>git remote rm origin
```

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

从远程仓库克隆

使用git clone命令即可克隆远程库到本地库，例如克隆远程库learnGit到本地某个仓库(文件夹)下，使用如下命令：

   推荐（SSH）：
       $ git clone git@github.com:userName/learnGit.git
   或者（HTTPS）：
       $ git clone https://github.com/userName/learnGit.git
   或者（Github CLI）：
       $ gh repo clone userName/learnGit

使用https除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令，但是在某些只开放 http 端口的公司内部就无法使用ssh协议而只能用https。

分支管理

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

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

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

该怎么去形容 “分支” 这个词？想象一下，一棵树有无数个分支，但只有一个最大的分支，这个最大的分支就是树干，其它分支就像是树枝一样。树枝上的嫩芽努力生长，努力长成树叶汲取太阳照射来的营养，并往树干乃至整棵树传输营养。分支也是如此，除一个常用的主分支外，还可以添加无数个分支，每个分支都可以独立完成各种任务，任务完成后，把结果合并给主分支，这样一来，主分支就获得了其它小分支源源不断的补给，最终的主分支就会无比壮大。万邦来朝上贡的感觉。
前面提到过HEAD，HEAD会随着分支走，也就是会不断地指向当前正在使用的分支，只有手动切换到其它分支后，HEAD才会将指针指向新的分支。

创建与合并分支

Git合并分支通过指针操作，即从指向当前分支转到指向欲转向的分支，通过指针操作，可以很迅速地完成合并分支。
合并完分支后，可以将不再需要的分支给删除。
先来创建一个dev分支，然后切换到dev分支：
```
   D:\learnGit>git branch dev
   
   D:\learnGit>git checkout dev
   Switched to branch 'dev'
```
然后用git branch命令查看当前分支：
```
   D:\learnGit>git branch
   * dev
     master
```
git branch命令会列出所有分支，当前分支前面会标出一个*号。

创建完后，就可以在dev分支上正常提交，比如对readme.txt末尾加上：

   Creating a new branch is dev.

然后提交：

   D:\learnGit>git add readme.txt
   
   D:\learnGit>git commit -m "branch dev"
   [dev de08de3] branch dev
    1 file changed, 2 insertions(+), 1 deletion(-)

现在，dev分支的工作完成，此刻就可以切换回master分支了：

   D:\learnGit>git checkout master
   Switched to branch 'master'

切换回master分支后，再查看readme.txt文件，刚才添加的内容不见了。这是因为刚才的那个提交是在dev分支上，而master分支此刻的提交状态并无改变。

   D:\learnGit>type readme.txt
   Git is a distributed version control system.
   Git is free software distributed under the GPL.
   Git tracks changes.

把dev分支的工作成果合并到master分支上：

   D:\learnGit>git merge dev
   Updating b8bd49e..de08de3
   Fast-forward
    readme.txt | 3 ++-
    1 file changed, 2 insertions(+), 1 deletion(-)

Fast-forward 即 “快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。

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

   D:\learnGit>type readme.txt
   Git is a distributed version control system.
   Git is free software distributed under the GPL.
   Git tracks changes.
   Creating a new branch is dev.

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

   D:\learnGit>git branch -d dev
   Deleted branch dev (was de08de3).

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

   D:\learnGit>git branch
   * master

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

切换分支

在创建分支的时候提到过，可以用git checkout <branch>命令切换到分支，但checkout命令也有另一个作用，那就是前面提到的git checkout -- <file>撤销修改命令。一个差不多的命令，有两种作用，这不太好。

在新版的Git中，Git提供了新的切换命令：git switch

创建并切换到dev分支，可以使用：

   D:\learnGit>git switch -c dev
   Switched to a new branch 'dev'

直接切换到已有的master分支，可以使用：
```
   D:\learnGit>git switch master
   Switched to branch '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>

解决冲突

先创建一个冲突。

新建一个分支branchTest，并切换到该分支：

   D:\learnGit>git switch -c branchTest
   Switched to a new branch 'branchTest'

修改readme.txt文件，在末尾加上：

   Creating a new branch is branchTest.

然后给分支提交该修改：

   D:\learnGit>git add readme.txt
   
   D:\learnGit>git commit -m "is branchTest"
   [branchTest b10638f] is branchTest
    1 file changed, 1 insertion(+), 1 deletion(-)

切换到master分支：

   D:\learnGit>git switch master
   Switched to branch 'master'

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

   Creating a new branch is not branchTest.

提交：

   D:\learnGit>git add readme.txt
   
   D:\learnGit>git commit -m "is not branchTest"
   [master 8239cd4] is not branchTest
    1 file changed, 1 insertion(+), 1 deletion(-)

现在，master和branchTest都有了提交。这种情况下，Git无法执行Fast-forward，只能试图把各自的修改合并起来，但这种合并就可能会有冲突。

尝试合并两个分支，在master分支上将branchTest合并过来：

   D:\learnGit>git merge branchTest
   Auto-merging readme.txt
   CONFLICT (content): Merge conflict in readme.txt
   Automatic merge failed; fix conflicts and then commit the result.

看吧，起冲突了。必须手动解决该冲突后，才能再次成功提交。git status可以列出冲突的文件：

   D:\learnGit>git status
   On branch master
   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")

此刻再用type命令列出readme.txt的内容：

   D:\learnGit>type readme.txt
   Git is a distributed version control system.
   Git is free software distributed under the GPL.
   Git tracks changes.
   <<<<<<< HEAD
   Creating a new branch is not branchTest.
   =======
   Creating a new branch is branchTest.
   >>>>>>> branchTest

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，在master分支下修改为与分支branchTest一致的内容，即修改readme.txt为如下内容：

注意，需要把<<<<<<<，=======，>>>>>>>这些内容删除。冲突的地方按需删除。

   Git is a distributed version control system.
   Git is free software distributed under the GPL.
   Git tracks changes.
   Creating a new branch is branchTest.

再在master分支下提交：

   D:\learnGit>git add readme.txt
   
   D:\learnGit>git commit -m "conflict fixed"
   [master 2d282e2] conflict fixed

用带参数的git log查看分支的合并情况：

   D:\learnGit>git log --graph --pretty=oneline --abbrev-commit
   *   2d282e2 (HEAD -> master) conflict fixed
   |\
   | * b10638f (branchTest) is branchTest
   * | 8239cd4 is not branchTest
   |/
   * de08de3 branch dev
   * b8bd49e remove testDel.txt
   * 82a936b add testDel.txt
   * 1b4d4d2 git tracks changes
   * 2d7ea27 append GPL
   * e528da2 add distributed
   * 44edf9b wrote a readme file

用git log --graph命令可以看到分支合并图。英文状态下按q键可以退出git log状态。

解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。最后，可以删除已完成任务的branchTest分支了：

   D:\learnGit>git branch -d branchTest
   Deleted branch branchTest (was b10638f).

分支管理策略

前面提到过，合并分支的时候，一般会出现Fast-forward，即快速 “快进模式” ，该模式合并后，没有一丝丝痕迹残留，但有时候想保留痕迹，那么就需要禁用快进模式，因为禁用后合并分支会生成一个新的commit，该commit可以用来记录该合并痕迹。

那就做个实验看看吧。

创建并切换到dev分支：

   D:\learnGit>git switch -c dev
   Switched to a new branch 'dev'

修改readme.txt文件，在末尾加上：This is dev.

   D:\learnGit>type readme.txt
   Git is a distributed version control system.
   Git is free software distributed under the GPL.
   Git tracks changes.
   This is dev.

给dev提交一个新的commit：

   D:\learnGit>git add readme.txt
   
   D:\learnGit>git commit -m "merge test"
   [dev 9c650e9] merge test
    1 file changed, 2 insertions(+), 1 deletion(-)

切换回master，并合并dev分支的工作成果。

   D:\learnGit>git switch master
   Switched to branch 'master'
   
   D:\learnGit>git merge --no-ff -m "merge with no-fast-forward" dev
   Merge made by the 'recursive' strategy.
    readme.txt | 3 ++-
    1 file changed, 2 insertions(+), 1 deletion(-)

请注意 --no-ff参数，表示禁用fast-forward。因为禁用fast-forward后，会生成一个新的commit，所以需要加上-m参数，把commit描述加上。

合并后，查看下分支历史，用git log命令：

   D:\learnGit>git log --graph --pretty=oneline --abbrev-commit
   *   a8fbbc2 (HEAD -> master) merge with no-fast-forward
   |\
   | * 9c650e9 (dev) merge test
   |/
   .....
   .....
   .....

> 总结：

master分支应该是非常稳定的，也就是仅仅用来发布新版本，平常不应在master分支上面干活。多开几个任务分支，如dev，等工作完成后，再将dev所得到的工作成功合并给master分支，让master分支发布版本。

Bug专用分支

手头的分支正在工作，且预计还需一段时间才能完成，但是出现了一个bug，需要紧急修复，但是手头上的分支工作还不能commit，为了不打扰到当前的分支工作，可以把当前的工作 ”冰冻储藏“，待Bug修复后把当前分支的工作恢复。完成该任务，需要用到stash功能。下面来进行一次Bug来临演示。

假设当前在dev分支工作，readme.txt文件末尾加上了一句话：Branch dev.

   D:\learnGit>type readme.txt
   Git is a distributed version control system.
   Git is free software distributed under the GPL.
   Git tracks changes.
   This master.
   Branch dev.

还想继续加内容，但是master分支的Bug却不给我时间，当务之急是修复Bug。因此，我暂时不把readme.txt commit 给dev分支。我决定将当前工作冻结，使用git stash命令：
```
   D:\learnGit>git stash
   Saved working directory and index state WIP on dev: 2d7ea27 merge with no-fast-forward
```

此刻，欲在master分支上修复Bug，就在master分支上创建临时分支：

   D:\learnGit>git switch master
   Switched to branch 'master'
   
   D:\learnGit>git switch -c issue-bug-001
   Switched to a new branch 'issue-bug-001'
   
   D:\learnGit>git branch
     dev
   * issue-bug-001
     master

在issue-bug-001分支上显示一下readme.txt文件的内容：

   D:\learnGit>type readme.txt
   Git is a distributed version control system.
   Git is free software distributed under the GPL.
   Git tracks changes.
   This master.

在issue-bug-001分支上，将readme.txt文件的最后一句话This master.修复为：This is master。在此，仅认为This master.就是一个Bug，修复该Bug就是将之修改为This is master.。

   D:\learnGit>type readme.txt
   Git is a distributed version control system.
   Git is free software distributed under the GPL.
   Git tracks changes.
   This is master.

好了，Bug修改好了，现在就是提交一个commit给issue-bug-001分支了。

   D:\learnGit>git add readme.txt
   
   D:\learnGit>git commit -m "fixed bug 001"
   [issue-bug-001 b5db786] fixed bug 001
    1 file changed, 1 insertion(+), 1 deletion(-)

修复完毕后，切换回master分支，并合并issue-bug-001分支，最后删除issue-bug-001分支：

   D:\learnGit>git switch master
   Switched to branch 'master'
   
   D:\learnGit>git merge --no-ff -m "merged issue-bug-001" issue-bug-001"
   Merge made by the 'recursive' strategy.
    readme.txt | 2 +-
    1 file changed, 1 insertion(+), 1 deletion(-)
   
   D:\learnGit>git branch -d issue-bug-001
   Deleted branch issue-bug-001 (was 9795cde).

接着显示一下readme.txt文件，可以看到Bug被修复：

   D:\learnGit>type readme.txt
   Git is a distributed version control system.
   Git is free software distributed under the GPL.
   Git tracks changes.
   This is master.

（请先看第⑧步，再看第⑦步）现在回到dev分区继续工作。使用git stash list命令可以显示正在冷藏中的工作：
```
   D:\learnGit>git stash list
   stash@{0}: WIP on dev: 8907f87 merge with no-fast-forward
```

stash@{0}就是冷藏ID，后续有多个冷藏列表且想要恢复指定stash的话，就需要这个ID。

果然还在 ”冷藏“ 中。”解冻“ 有两个办法：

使用git stash apply命令恢复，但是恢复后，stash list中的记录并不会消失，还需要继续使用git stash drop命令来删除。如果要指定某个stash恢复，那么需要加上ID，如：git stash list stash@{0}。

使用git stash pop命令恢复并删除stash list中的记录。

任选一个，我选择第二种方式：

   D:\learnGit>git stash pop
   On branch dev
   Changes not staged for commit:
     (use "git add <file>..." to update what will be committed)
     (use "git restore <file>..." to discard changes in working directory)
           modified:   readme.txt
   
   no changes added to commit (use "git add" and/or "git commit -a")
   Dropped refs/stash@{0} (21d49e14baa879a21984e014a176d31e7d8ab2ab)

再使用git stash list命令，就看不到任何stash记录了。显示一下readme.txt文件的内容，还是冷冻前的工作状态：

   D:\learnGit>type readme.txt
   Git is a distributed version control system.
   Git is free software distributed under the GPL.
   Git tracks changes.
   This master.
   Branch dev.

> > 如果在dev分支下也有master分支继承来的Bug（毕竟dev来源于master），那么dev分支也是需要修复这个Bug的，那么该怎么办？

注意：因为还有个stash在冰冻中，所以应先修复Bug再解冻，否则会出现不可描述的错误，至少这个错误在当前我还找不到办法去解决。

同样的Bug，要在dev上修复，只需要复制master分支上的commit记录fixed bug 001到dev分支即可。注意，此处仅是复制fixed bug 001这个commit所作的修改，并不会把整个master分支复制过来。

为了方便操作，Git提供了git cherry-pick <commitId>命令，用于复制其它分支中某个特定的commit到当前分支。首先回到master分支，查看commit记录中fixed bug 001的 Commit ID。

   D:\learnGit>git log --graph --pretty=oneline --abbrev-commit
   * 8907f87 (HEAD -> dev) this master
   *   dcaa0ce merged issue-bug-001
   |\
   | * b5db786 fixed bug 001

b5db786即fixed bug 001的ID，切换回dev分支，将这个记录复制给dev分支：

   D:\learnGit>git cherry-pick b5db786
   [dev 18a04ad] fixed bug 001
    Date: Thu Oct 28 16:36:18 2021 +0800
    1 file changed, 1 insertion(+), 1 deletion(-)

查看下当前的readme.txt文件：

   D:\learnGit>type readme.txt
   Git is a distributed version control system.
   Git is free software distributed under the GPL.
   Git tracks changes.
   This is master.

很好，This master成功复制了master分支下的修复，变为了This is master。

此时再去解冻stash，回到步骤7。

多人协作

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

2020年，为了避免卷入 “Black Lives Matter” 运动，Github将默认的master分支更名为main分支。

要查看远程库的信息，用git remote，加上-v参数显示更详细的信息：

  D:\learnGit>git remote
  origin
  
  D:\learnGit>git remote -v
  origin  git@github.com:userName/learnGit.git (fetch)
  origin  git@github.com:userNamelearnGit.git (push)

使用git push来推送分支，即把该分支上的所有文件推送到远程库，推送时，要指定本地分支：
```
  git push -u origin main
  //推送本地 main 分支到远程库的 origin 分支上
```

拉取分支(pull)

现在，假设有一位共同开发的小伙伴。该小伙在他工作的目录下克隆了远程库：

D:\Giter>git clone git@github.com:userName/learnGit.git
Cloning into 'learnGit'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.

默认情况下，该小伙只能看到本地的main分支：

D:\Giter>cd ./learnGit

D:\Giter\learnGit>git branch
* main

如果他想在dev分支上开发，那么需要创建一个远程origin的dev分支到本地：

D:\Giter\learnGit>git checkout -b dev origin/dev
Switched to a new branch 'dev'
Branch 'dev' set up to track remote branch 'dev' from 'origin'.

D:\Giter\learnGit>git branch
* dev
  main

如果在执行上面代码的时候出现了如下问题：

D:\Giter\learnGit>git checkout -b dev origin/dev
fatal: 'origin/dev' is not a commit and a branch 'dev' cannot be created from it

那么需要先git pull一下，即先从远程库上拉取数据。因为可能git clone的时候，远程库还没有dev分支。

D:\Giter\learnGit>git pull
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), 259 bytes | 1024 bytes/s, done.
From github.com:thrfur/learnGit
 * [new branch]      dev        -> origin/dev
Already up to date.

现在，该小伙可以在dev分支上工作了，且可以时不时地git push到dev分支。

D:\Giter\learnGit>type readme.txt
learnGit/readme.txt
dev.
origin/dev.

D:\Giter\learnGit>git add readme.txt

D:\Giter\learnGit>git commit -m "origin/dev"
[dev 56846b2] origin/dev
 1 file changed, 2 insertions(+), 1 deletion(-)
 
D:\Giter\learnGit>git push -u origin dev
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Writing objects: 100% (3/3), 288 bytes | 288.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To github.com:thrfur/learnGit.git
   83bd098..56846b2  dev -> dev
Branch 'dev' set up to track remote branch 'dev' from 'origin'.

此时，小伙伴在dev分支工作，我也在dev工作，他提交完了修改到origin仓库，我修改好了我这边在dev分支的文件，也需要上传到origin仓库，这时候提交上去可能会出现错误。

下面在我这边以dev分支的身份推送：

   D:\Giter\learnGit>git push -u origin dev
   To github.com:userName/learnGit.git
    ! [rejected]        dev -> dev (fetch first)
   error: failed to push some refs to 'github.com:thrfur/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 pull，把最新的 push 从origin/dev拉取下来，然后在本地合并、解决冲突，再 push：

   D:\Giter\learnGit>git pull
   remote: Enumerating objects: 5, done.
   remote: Counting objects: 100% (5/5), done.
   remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
   Unpacking objects: 100% (3/3), 268 bytes | 1024 bytes/s, done.
   From github.com:thrfur/learnGit
      984c6bd..a749990  dev        -> origin/dev
   Auto-merging readme.txt
   CONFLICT (content): Merge conflict in readme.txt
   Automatic merge failed; fix conflicts and then commit the result.

如果 git pull出现no tracking information错误：

$ git pull
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

则说明需要建立本地分支与远程分支的链接关系，解决办法为：

D:\Giter\learnGit>git branch --set-upstream-to=origin/dev dev
Branch 'dev' set up to track remote branch 'dev' from 'origin'.

继续，很明显，文件冲突了：

   D:\Giter\learnGit>type readme.txt
   learnGit/readme.txt
   origin/dev.
   <<<<<<< HEAD
   Windows11.friends
   =======
   Windows7.friends
   >>>>>>> a749990ad53961060dbed8138db1aa77f9dc6561

删除部分后：

   D:\Giter\learnGit>type readme.txt
   learnGit/readme.txt
   origin/dev.
   Windows11.friends

然后添加并提交：

   D:\Giter\learnGit>git add readme.txt
   
   D:\Giter\learnGit>git commit -m "pull and fix conflict"
   [dev 0ad919d] pull and fix conflict

这时候，就可以正常 push 到 origin/dev了：

   D:\Giter\learnGit>git push -u origin dev
   Enumerating objects: 10, done.
   Counting objects: 100% (10/10), done.
   Delta compression using up to 6 threads
   Compressing objects: 100% (3/3), done.
   Writing objects: 100% (6/6), 616 bytes | 154.00 KiB/s, done.
   Total 6 (delta 0), reused 0 (delta 0), pack-reused 0
   To github.com:thrfur/learnGit.git
      a749990..0ad919d  dev -> dev
   Branch 'dev' set up to track remote branch 'dev' from 'origin'.

可以看到，在多人协作的过程中，很容易出现冲突。即便没有冲突，后 push 的小伙伴不得不先 pull，在本地合并，然后才能 push 成功。

Rebase

不是刚需。

标签管理

用 commit id 去描述一个推送，显然不太精简。commit id 冗长且无规律，如果能有个自定义代号来代替 commit id 岂不是更完美。标签与 commit id 的关系就像 ip 与域名的干系，别名而已。

创建标签

现在要给main分支的最新一个 commit 创建一个标签 “v1.0”，使用git tag <tagName>命令，不加上 commit ID 的话，默认给最新一个提交的 commit 加上标签。

D:\Giter\learnGit>git branch
  dev
* main

D:\Giter\learnGit>git log --pretty=oneline --abbrev-commit
b1c336f (HEAD -> main, origin/main, origin/HEAD) origin/main
d346aef first commit

D:\Giter\learnGit>git tag @beta-0.1 d346aef

D:\Giter\learnGit>git tag v1.0 b1c336f //最新的提交也可以不加 commit ID

使用git tag命令查看所有标签：

D:\Giter\learnGit>git tag
@beta-0.1
v1.0

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

D:\Giter\learnGit>git show v1.0
commit b1c336f93df779b844a397f37e2d330c2107de7b (HEAD -> main, tag: v1.0, origin/main, origin/HEAD)
.....
.....

标签v1.0已精确绑定了commit ID为 b1c336f93d....的提交。

还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字：

D:\Giter\learnGit>git tag -a v1.0 -m "stable v1.0 released" b1c336f

D:\Giter\learnGit>git show v1.0
tag v1.0
Tagger: thrfur <47554753+thrfur@users.noreply.github.com>
Date:   Fri Oct 29 21:37:31 2021 +0800

stable v1.0 released

commit b1c336f93df779b844a397f37e2d330c2107de7b (HEAD -> main, tag: v1.0, origin/main, origin/HEAD)
.....
.....

管理标签

删除标签使用git tag -d <tagName>命令：

D:\Giter\learnGit>git tag -d @beta-0.1
Deleted tag '@beta-0.1' (was d346aef)

推送标签到远程仓库使用git push origin <tagName>命令：

D:\Giter\learnGit>git push origin v1.0
Enumerating objects: 1, done.
Counting objects: 100% (1/1), done.
Writing objects: 100% (1/1), 176 bytes | 176.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
To github.com:thrfur/learnGit.git
 * [new tag]         v1.0 -> v1.0

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

D:\Giter\learnGit>git push origin --tags

删除已 push 到远程的标签，得先从本地删除，然后从远程删除：

D:\Giter\learnGit>git tag -d v1.0
Deleted tag 'v1.0' (was daee16e)

D:\Giter\learnGit>git push origin :refs/tags/v1.0
To github.com:thrfur/learnGit.git
 - [deleted]         v1.0