Git 学习

首先推荐廖雪峰老师的Git:www.liaoxuefeng.com/wiki/896043…

Git简介

在b站，掘金，CSDN等等上面都看过一些git 但是都是讲一些比较破碎的东西，然后找到了廖雪峰老师的Git文章，收获很多，在工作中很多场景都能够用上。

安装Git

因为我使用的是window说，所以介绍在Windows上安装Git，可以从Git官网直接下载安装程序，然后按默认选项安装即可。

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

在安装完成之后，还需要进行配置

$ git config --global user.name "github上的名字"

$ git config --global user.email "github对应的邮箱号"

--global 参数表示，所有的Git仓库都会使用这个配置，但是同样也可以单独对某个仓库使用用户名和Email

创建版本库

可以简单的理解为目录，目录中的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。

所以首先选择一个合适的地方，创建一个空目录：

$ mkdir learngit 
$ cd learnigt
$ pwd

pwd 命令用于显示当前目录。

然后开始第二步，将这个目录变成Git可以管理的仓库，使用的命令是git init

$ git init
Initialized empty Git repository in F:/Git/learngit/.git/

这就成为了Git仓库，此时你会发现目录下面多了.git的目录文件，这是Git管理版本库的，不要随意修改。如果你没有看到.git目录，那是因为这个目录默认是隐藏的，可以点击查看>显示>隐藏的项目，然后就可以看见。也可以用ls -ah命令就可以看见。

在刚刚创建的目录下面创建readme.txt ,内容：

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

然后开始将文件放入到Git仓库中。第一步：用命令git add告诉Git，把文件添加到仓库：

$ git add readme.txt

执行之后没有任何显示。第二步:用命令git commit告诉Git，把文件提交到仓库

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

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

总结： git init 初始化Git仓库。

添加文件到Git仓库，分两步：

使用命令git add <file>，注意，可反复多次使用，添加多个文件；
使用命令git commit -m <message>，完成。

时光穿梭

刚开始的时候不明白为啥会取名叫时光穿梭，但是学完这一小部分，回来查看，发现，确实跟时光穿梭一样。

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

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

运行git status命令看看结果

$ 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 diff readme.txt
diff --git a/readme.txt b/readme.txt
index d8036c1..7b4104a 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.

知道了对readme.txt作了什么修改后，就可以放心的再次提交。

$ git add readme.txt

执行提交之前可以查看当前仓库的状态:

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

告诉我们，将要提交的包括readme.txt，然后可以放心的提交。

$ git commit -m "two commit"
[master 1ca5ded] two commit
 1 file changed, 1 insertion(+), 1 deletion(-)

再次查看仓库当前的状态：

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

提交

$ git add readme.txt
$ git commit -m "three commit"
[master 31619dc] three commit
 1 file changed, 1 insertion(+), 1 deletion(-)

我们可以使用git log命令查看我们历史记录

$ git log
commit 31619dc5488276cb508d0b612527d6d7a5b16f86 (HEAD -> master)
Author: “forever0714yuan” <1141395452@qq.com>
Date:   Mon Mar 7 10:02:28 2022 +0800

    three commit

commit 1ca5dedbad451ff07ac922b9f79617878f182e23
Author: “forever0714yuan” <1141395452@qq.com>
Date:   Mon Mar 7 09:57:08 2022 +0800

    two commit

commit 3fb5f4c3a49e672446794c0bdf9ddfebf0c86601
Author: “forever0714yuan” <1141395452@qq.com>
Date:   Mon Mar 7 09:32:13 2022 +0800

    first commit

版本1 first commit

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

版本2 two commit

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

版本3 three commit

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

git log命令显示从最近到最远的提交日志，我们可以看到3次提交，最近的一次是three commit，上一次是two commit，最早的一次是first commit。

如果嫌输出信息太多，看得眼花缭乱的，可以试试加上--pretty=oneline参数：


$ git log --pretty=oneline
31619dc5488276cb508d0b612527d6d7a5b16f86 (HEAD -> master) three commit
1ca5dedbad451ff07ac922b9f79617878f182e23 two commit
3fb5f4c3a49e672446794c0bdf9ddfebf0c86601 first commit

31619dc....是commit id（版本号）

开始准备回退。

首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交31619dc548...（注意我的提交ID和你的肯定不一样），上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。

使用git reset命令:

$ git reset --hard HEAD^
HEAD is now at 1ca5ded two commit

此时就从three commit变成了two commit 再次查看readme.txt的内容是不是版本two comiit

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

再次使用git log查看

$ git log
commit 1ca5dedbad451ff07ac922b9f79617878f182e23 (HEAD -> master)
Author: “forever0714yuan” <1141395452@qq.com>
Date:   Mon Mar 7 09:57:08 2022 +0800

    two commit

commit 3fb5f4c3a49e672446794c0bdf9ddfebf0c86601
Author: “forever0714yuan” <1141395452@qq.com>
Date:   Mon Mar 7 09:32:13 2022 +0800

    first commit

发现版本3 已经看不到了。想要回去的方法，

只要上面的命令行窗口还没有被关掉，你就可以顺着往上找啊找啊，找到那个three commit的commit id是31619d...，于是就可以指定回到未来的某个版本：

$ git reset --hard 31619
HEAD is now at 31619dc three commit

版本号没必要写全，前几位就可以了，Git会自动去找。当然也不能只写前一两位，因为Git可能会找到多个版本号，就无法确定是哪一个了。

然后查看readme.txt的内容

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

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

┌────┐
│HEAD│
└────┘
   │
   └──> ○ three commit
        │
        ○ two commit
        │
        ○ first commit

改为指向two commit:

┌────┐
│HEAD│
└────┘
   │
   │    ○ three commit
   │    │
   └──> ○ two commit
        │
        ○ first commit

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

但是突然手抽抽把窗口关闭了，又想要恢复到three commit，又找不到three commit的版本号，怎么办。

在Git中，总是有后悔药可以吃的。当你用$ git reset --hard HEAD^回退到two commit版本时，再想恢复到three commit，就必须找到three commit的commit id（版本号）。Git提供了一个命令git reflog用来记录你的每一次命令：

$ git reflog
31619dc (HEAD -> master) HEAD@{0}: reset: moving to 31619
1ca5ded HEAD@{1}: reset: moving to HEAD^
31619dc (HEAD -> master) HEAD@{2}: commit: three commit
1ca5ded HEAD@{3}: commit: two commit
3fb5f4c HEAD@{4}: commit (initial): first commit

然后可以查看到，three commit的版本号是31619dc,然后就可以恢复了

总结：

HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。
穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。
要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。

工作区和暂存区

#### 工作区（Working Directory）

在前面我们创建的learngit文件夹就是一个工作区

#### 版本库（Repository）

在工作区中，有个隐藏的目录.git，这个就是Git的版本库

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

我们在将文件提交的时候

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

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

我们在创建版本库的时候，Git自动给我们创建了main分支，所以现在我们提交就是向main分支上提交的

简单来说就是，将需要提交的文件都放在暂存区，然后可以一次性提交暂存区的修改。

再次对readme.txt做出修改

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

然后新增加一个文件，内容是

my name is 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 restore <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 restore --staged <file>..." to unstage)
        new file:   LICENSE
        modified:   readme.txt

现在的缓存区

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

$ git commit -m "four commit"
[master 6368e1e] four commit
 2 files changed, 3 insertions(+), 1 deletion(-)
 create mode 100644 LICENSE

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

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

总结：

1、理解工作区和缓存区的定义。

2、明白在add和commit之间Git的操作过程。

管理修改

什么Git比其他版本控制系统设计得优秀，因为Git跟踪并管理的是修改，而非文件。

什么是修改？比如你新增了一行，这就是一个修改，删除了一行，也是一个修改，更改了某些字符，也是一个修改，删了一些又加了一些，也是一个修改，甚至创建一个新文件，也算一个修改。

为什么说Git管理的是修改，而不是文件呢？实践证明

第一步对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.

第二步：添加

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

第三步：修改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.

第四步：提交

$ git commit -m "five commit"
[master f9519d4] five commit
 1 file changed, 2 insertions(+), 1 deletion(-)

提交之后，再次查看状态：

$ 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管理的是修改，当你用git add命令后，在工作区的第一次修改被放入暂存区，准备提交，但是，在工作区的第二次修改并没有放入暂存区，所以，git commit只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次的修改不会被提交。

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

$ git diff HEAD -- readme.txt
diff --git a/readme.txt b/readme.txt
index d8f06ec..ea1bb9c 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.
\ No newline at end of file
+Git tracks changes of files.
\ No newline at end of file

可见，第二次修改确实没有被提交。

总结 1、Git如何跟踪修改，每次修改如果不添加到暂存区，就不会被提交。

撤销修改

人不可能不犯错，但你晚上两点还在肝的时候，在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 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告诉你，使用git restore <file>可以丢弃工作区的修改

git restore readme.txt

此时你会发现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.

文件复原了。

如果你已经将修改添加到了暂存区

$ 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.
My stupid boss still prefers SVN.
$ git add readme.txt

在commit之前,你发现了这个问题。使用git status 查看了一下，发现只是将修改添加到了暂存区。

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

Git告诉我们，使用git restore --staged <file>可以将暂存区的修改撤销掉，重新回到工作区。

再来git status查看一下，发现暂存区干净了，工作区有了修改。

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

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

现在，假设你不但改错了东西，还从暂存区提交到了版本库，怎么办呢？可以回退到上一个版本。不过，这是有条件的，就是你还没有把自己的本地版本库推送到远程。Git是分布式版本控制系统，一旦你把stupid boss提交推送到远程版本库，那就直接G了啊

总结： 1、git restore <file> 丢弃工作区的修改。 2、git restore --staged <file> 可以将暂存区的修改撤销掉，重新回到工作区。

删除文件

删除文件也是修改操作的一种，先添加一个新文件 test.txt到Git并提交

$ git add test.txt
$ git commit -m "six commit"
[master ebef238] six commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 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 restore <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 six commit"
[master 66ef8e5] remove six commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 test.txt

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

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

$ git restore test.txt

总结： 1、命令 git rm <file>用于删除一个文件。

远程仓库

如果只是在一个仓库里管理文件历史，Git和SVN真没啥区别。现在学习的是Git强大的功能之一：远程仓库

Git是分布式版本控制系统，同一个Git仓库，可以分布到不同的机器上。那么我们就在想如何分布呢？

最早，只有一台机器有一个原始版本库，然后，别的机器可以“克隆”这个原始版本库，而且每台机器的版本库其实都是一样的，并没有主次之分。

而且一台电脑上也是可以克隆多个版本库的，只要不在同一个目录下。不过，在一台电脑上搞几个远程库完全没有意义，而且硬盘挂了会导致所有库都挂掉。（在一台电脑上怎么克隆多个仓库？）

实际情况往往这样，找一台电脑充当服务器的角色，每天24小时开机，其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。

这个世界上有个叫GitHub的网站，这个网站就是提供Git仓库托管服务的，所以，只要注册一个GitHub账号，就可以免费获得Git远程仓库。

后面的学习需要用到Github，所以请根据操作自行注册GitHub账号。由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的，所以，需要一点设置：

第1步：创建SSH Key。

在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步（如果你之前是不懂git的，跟着某些教程一顿操作后发现能用，就没有管他了，这种情况还是建议删除.ssh目录后重新生成。因为我就是这样的，之后我才发现进行的配置是有一些不对劲。）。

如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：

$ ssh-keygen -t rsa -C "youremail@example.com"//你的邮箱

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

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

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

然后进去之后点击New SSH key，我这个因为是配置过，所以有一个，如果从来没有配置过的应该是没有key的

进入之后添加公钥，点“Add SSH Key”，你就应该看到已经添加的Key：

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

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

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

如果你不想让别人看到Git库，有两个办法，一个是把GitHub的仓库创建成私有的，这样别人就看不见了。另一个办法是自己动手，搭一个Git服务器，因为是你自己的Git服务器，所以别人也是看不见的。

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

总结： 1、学习github的注册和配置

添加远程库

本地创建了一个Git仓库后，GitHub上创建了一个Git仓库，并且让两个仓库进行远程同步。

（1）登录GitHub，new repository 创建一个新的仓库,这里我创建了一个名为：hanStudy的仓库。

（2）在 Repository name 的那一栏输入hanStudy，点击第三步的 Create repository 的按钮，就创建成功一个新的Git仓库。

现在这个仓库中是空的，他给了你三种提示：从这个仓库克隆出新的仓库、把一个已有的本地仓库与之关联、从另一个存储库导入代码。

根据GitHub的提示，在本地创建一个（仓库）文件，名字叫hanStudy，接下来开始进行链接。

第一步：创建一个README.md文件，作用是对项目的主要信息进行描述

echo "# hanStudy" >> README.md

第二步：仓库的初始化

git init

第三步：跟踪README.md文件，或者说将内容从工作目录添加到暂存区。

git add README.md

这里可能会出现一个警告warning: LF will be replaced by CRLF in README.md. ，出现这个警告的原因是在windows系统中的换行符是CRLF，Linux和Unix的系统的换行符是LF,换行符的不同，导致了跨平台的协作的项目带来了问题，保存文件使用那个标准？git为了解决这个问题，就提供了一个换行符自动转换的功能，这个功能是默认开启的。

这个换行符自动转换会把自动把你代码里的与你当前操作系统不相同的换行的方式转换成当前系统的换行方式（即LF和CRLF 之间的转换），这样一来，当你提交代码的时候，即使你没有修改过某个文件，也被git认为你修改过了，从而提示 LF will be replaced by CRLF in.... 的警告，这个警告是几乎没有影响的，所以忽略这个警告就可以了。

第四步：将暂存区的内容添加到本地仓库中。

git commit -m "first commit"

第五步：把当前master分支改名为main, 其中-M的意思是移动或者重命名当前分支。

git branch -M main

第五步：关联远程仓库

git remote add origin https://github.com/forever0714yuan/hanStudy.git

添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。第六步:将本地仓库的所有内容推送到远程仓库。

git push -u origin main

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

然后可以看到远程仓库的内容发送了改变,内容和本地的一模一样了。

现在，本地做了提交，就可以将本地main分支最新的修改推到远程仓库。

git push origin main

SSH警告

当你第一次使用Git的clone或者push命令连接GitHub时，会有警告：

The authenticity of host 'github.com (xx.xx.xx.xx)' can't be established.
RSA key fingerprint is xx.xx.xx.xx.xx.
Are you sure you want to continue connecting (yes/no)?

这是因为Git使用SSH连接，而SSH连接在第一次验证GitHub服务器的Key时，需要你确认GitHub的Key的指纹信息是否真的来自GitHub的服务器，输入yes回车即可。

Git会输出一个警告，告诉你已经把GitHub的Key添加到本机的一个信任列表里了：

Warning: Permanently added 'github.com' (RSA) to the list of known hosts.

这个警告只会出现一次，后面的操作就不会有任何警告了。

删除远程库

当我们想要删除远程库，或者是关联远程库的时候地址错误了，可以先用git remote -v查看远程库信息：

$ git remote -v
origin  https://github.com/forever0714yuan/hanStudy.git (fetch)
origin  https://github.com/forever0714yuan/hanStudy.git (push)

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

git remote rm origin

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

问题

1、输入git push -u origin main之后加卡住。解决办法：（1）关了bash重开重新输指令，可能是电脑问题。（2）因为需要等你GitHub授权，所以它会跳转出一个GitHub授权网页，需要你登录GitHub账户验证。自己仔细的注意一下。

总结： 1、连接远程库，使用的是git remote add origin https://github.com/forever0714yuan/hanStudy.git 关联远程库的时候要远程库指定一个名字，origin是默认习惯命名。 2、关联之后可以使用命令git push -u origin master第一次推送mian分支的所有内容；此后，每次本地提交后，只要有必要，就可以使用命令git push origin main推送最新修改。 3、删除远程库，使用git remote rm origin

从远程库克隆

创建远程库，然后从远程库进行克隆。

登录GitHub,创建一个仓库，名字叫hanStudy2.

这里我们勾选了Add a README file，然后我们创建之后发现了，GitHub自动为我们创建了一个README.md的文件，可以看到里面的内容。

然后我们在项目的右上角找到叫code的按钮，将里面的HTTPS复制好，然后在本地打开Git工具，使用git clone命令克隆仓库，记得将链接换成自己的。

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

这里跟你的网速有关，你可能发现如下的错误，自己的请求一直超时，等网络好的时候再克隆试试

$ git clone https://github.com/forever0714yuan/hanStudy2.git
Cloning into 'hanStudy2'...
fatal: unable to access 'https://github.com/forever0714yuan/hanStudy2.git/': Failed to connect to github.com port 443 after 21096 ms: Timed out

成功之后，你就会发现自己的目录下有这个hanStudy2的项目了。

GitHub给出的地址不止一个，还可以用git@github.com:forever0714yuan/hanStudy2.git，这样的地址，这是因为Git支持多种协议，默认的git://使用ssh，但也可以使用https等其他协议。

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

总结： 1、使用git clone命令来克隆远程仓库。 2、Git支持多种协议，包括https，但ssh协议速度最快。

分支管理

看到这里我一下就想到了《火影忍者》，鸣人有个从小打到大的技能，多重影分身，这个影分身有个特点就是，多个影分身之间互不干扰，但是当影分身消失的时候，自己（本体）就可以知道影分身这段时间内所作的事情。这里的分支有点儿类似。

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

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

创建与合并分支

每次提交，Git会将它们串成一条时间线，这个时间线就是一个分支。截止目前学习为止，只有一条时间线，在Git的分支中，这叫主分支，即master 分支，HEAD 严格来说不是指向提交，而是指向 master,master才是指向提交，HEAD 指向的就是当前分支。

刚开始的时候，master分支是一条线，Git用 master 指向最新的提交，再用 HEAD指向 master，就是能确定当前分支，以及当前分支的提交点

每次的提交，master 分支都会向前移动一步，这样的话，不断的提交，master分支的线也就是越来越长。

当我们创建新的分支，例如dev 时，Git新建一个指针叫dev，指向master 相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

我们发现，新增了一个dev指针，将 HEAD的指向指向dev，工作区的内容没有变化!

我们从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

如果我们在dev上的工作完成了，就可以把dev合并到master上。最简单的方法，就是直接将master指向dev的当前提交，就完成了合并：

所以Git合并分支很快，改变指针的指向，工作区内容不变！

合并完分支后，就可以将dev分支删除了，删除dev分支就是将dev 指针给删掉，删掉之后，我们就只剩下一条master分支：

下面开始进行实战 1、创建dev分支，然后切换到dev分支：

$ git checkout -b 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：

$ git commit -m '第一次提交'
[dev 8828867] 第一次提交
 1 file changed, 1 insertion(+)
 create mode 100644 README.txt

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

$ git checkout master
Switched to branch 'master'

切换回master 分支后，再查看一个README.txt文件，你会发现一个奇怪的问题，你刚刚的操作都没了，因为我们刚刚的提交是在dev分支上，而master分支此刻的提交点并没有改变，所以才会出现这种情况。

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

$ git merge dev
Updating 1349f76..8828867
Fast-forward
 README.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 README.txt

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

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

当然，也不是每次合并都能Fast-forward，合并完成后，就可以放心地删除dev分支了：

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

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

$ git branch
* master

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

switch

我们注意到切换分支使用git checkout <branch>，而前面讲过的撤销修改则是git checkout -- <file>，同一个命令，有两种作用，确实有点令人迷惑。

实际上，切换分支这个动作，用switch更科学。因此，最新版本的Git提供了新的git switch命令来切换分支：

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

$ git switch -c dev

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

$ git switch master

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

小结

1、这章学习了分支的使用：（1）查看分支：git branch （2）创建分支：git branch <name> （3）切换分支：git checkout <name> 或 git switch <name> （4）创建+切换分支：git checkout -b <name> 或 git switch -c <name> （5）合并某分支到当前的分支：git merge <name> （6）删除分支：git branch -d <name>