Git 原理及使用 (带动图演示)

🌈 Ⅰ Git 安装

🌙 01. Linux - centos

• 在 centos 7.6 下使用 yum 指令安装 git 软件。

sudo yum install -y git

🌈 Ⅱ Git 工作区、暂存区和版本库

🌙 01. 认识工作区、暂存区和版本库

• 工作区：在电脑中能够看到的目录。
• 暂存区：英文叫 stage 或 index。⼀般存放在 .git ⽬录下的 index 文件（.git / index）中，所以把暂存区有时也叫作索引（index）。
• 版本库：又叫做仓库，工作区有⼀个隐藏目录 .git ，它不算工作区，而是 Git 的版本库。这个版本库里面的所有文件都可以被 Git 管理起来，每个文件的修改、删除，Git 都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以 “还原”。

• 注意：不允许直接对 git 的版本库进行修改，即不能在 .git 版本库中新建文件。

🌙 02. 使用 Git 管理工作区的文件

1. 通过 git add 将工作区的所有修改 (或新增) 内容添加到版本库的暂存区 (stage) 中。
2. 通过 git commit 将暂存区中的内容提交到 master 分支下，此时才算是将要管理的内容真正放到版本库中。执行完这两步之后，才能用 git 管理自己的文件。

🌈 Ⅲ Git 基本操作

🌙 01. 创建本地仓库

git init

1. 创建一个新目录。
2. 使用 cd 指令进入该目录。
3. 在该目录下使用 git init 指令创建本地仓库。
4. 最后再在该目录下使用 ls -al 指令，如果出现了个 .git 目录，即本地仓库创建成功。
   • 动图演示：

🌙 02. 配置本地仓库

• 创建完本地仓库后，要为本地仓库创建 name 用户名 和 email 用户邮箱 两个配置项才能使用。

⭐ 2.1 创建 & 删除局部配置项

• 为当前所处的本地仓库创建配置项。

1. 创建局部配置项

1. 配置 name：git config user.name "你的用户名"
2. 配置 email：git config user.name "你的用户邮箱"

2. 查看本地仓库配置

• 查看本地仓库下的所有配置项 git config -l。

3. 删除局部配置项

1. 删除 name 配置：git config --unset user.name
2. 删除 email 配置：git config --unset user.email

⭐ 2.2 创建 & 删除全局配置项

• 将创建的配置项生效于当前机器下的所有本地 git 仓库。
• 在任意 git 仓库下都能使用配置的同一个 name 和 email 配置项。

1. 创建全局配置项

1. 为所有本地仓库创建 name 配置项：git config --global user.name "你的用户名"
2. 为所有本地仓库创建 email 配置项：git config --global user.email "你的用户邮箱"

2. 删除全局配置项

1. 删除全局的 name 配置项：git confit --global --unset user.name
2. 删除全局的 email 配置项：git confit --global --unset user.email

🌙 03. 添加文件

• 当前有一个 ReadMe 文件，现在以将它提交到版本库中举例。

⭐ 3.1 git add 添加文件到暂存区

add 文件的方式有多种

1. 添加一个或多个文件到暂存区：git add 文件1 文件2 ... 文件n
2. 添加指定目录到暂存区，包含子目录：git add 目录名
3. 添加当前目录下所有文件的改动到暂存区：git add .

⭐ 3.2 git commit 将暂存区内容提交到本地仓库

commit 文件的方式有多种

1. 提交暂存区全部内容到本地仓库中：git commit -m "message"
2. 提交暂存区的指定文件到仓库中：git commit 文件1 文件2 ... 文件n -m "message"
   • message 用于描述本次提交的文件。
   • 动图演示：

🌙 04. 修改文件

• git 追踪管理的其实是修改，而不是文件。
• 现在对 ReadMe 文件进行修改，此时仓库中的 ReadMe 和工作区的 ReadMe 是不同的。

⭐ 4.1 git status 查看当前仓库状态

• 该命令用于查看在你上次提交之后是否有对文件进行再次修改。

• 但是，该指令只能知道文件被修改，却不能知道该文件是那里被修改了。

⭐ 4.2 git diff 显示文件在暂存区和工作区的差异

• 显示暂存区和工作区的差异：git diff 文件名
• 显示暂存区和上一次 commit 的差异：git diff --cached 文件名
  • 动图演示：

🌙 05. 版本回退

• Git 能够管理文件的历史版本，如果哪天发现工作出现了问题，需要在某个特定的历史版本重新开始，此时就需要用到版本回退的功能了。
  • 对一个文件的每一次 add 和 commit 可以看成一个版本。
• 可以执行 git reset 指令用于回退版本，可以指定回退到某一次提交的版本。
  • “回退” 本质是将版本库中的内容进行回退，工作区或暂存区是否回退由命令参数决定。

⭐ 5.1 git reset 语法格式

git reset [--soft | --mixed | --hard] [HEAD]

1. --soft：对于工作区和参数区的内容都不变，只用于将版本库回退到指定版本。

2. --mixed：默认选项，使用时可以不带该参数，用于将暂存区和版本库回退到指定版本，工作区文件内容保持不变。

3. --hard (慎用)：撤销工作区中所有未提交的修改内容，将工作区、暂存区和版本库都回退到指定版本。因为会让工作区回滚，因此在工作区有未提交的代码时切记不要使用该命令。

4. HEAD：用来指定要回退的版本，有两种指定回退版本的方式。

1. 用 ^ 的个数表示回退的版本				2. 用 ~ + 数字 表示回退的版本
HEAD		当前版本		HEAD~0		当前版本
HEAD^		上一个版本		HEAD~1		上一个版本
HEAD^^		上上个版本		HEAD~2		上上个版本
HEAD^^^		上上上个版本		HEAD~3		上上上个版本
以此类推				以此类推

🌙 06. 撤销修改

• 在工作区中写了很长时间的代码，觉得写的太挫了，想将工作区恢复到上个版本。
• 恢复工作区到上个版本时工作区有 3 种情况：
  1. 还未对工作区的代码进行 add 操作。
  2. 已对工作区进行 add，但还没有执行 commit 操作。
  3. 对工作区的代码 add 和 commit 什么都干了。
• 现在就分别对这三种情况分开讨论如何恢复。

⭐ 6.1 还未对工作区的代码执行 add 操作

• 修改后的内容只存在于工作区，暂存区和版本库没有这段被修改的内容。
  • 这种情况下，只撤销工作区中的修改内容即可。

git checkout -- 文件名	// -- 用于将工作区文件回退到最近一次 add 或 commit 的状态 

• 动图演示：

⭐ 6.2 已经 add 但还没有执行 commit

• 修改的内容存在于工作区和暂存区，版本库没有这段被修改的内容。
  • 这种情况下，要将工作区和暂存区都撤销到上个版本。

git reset --mixed HEAD ReadMe	// 将暂存区和版本库回退到当前版本，此时修改只存在于工作区
git checkout -- 文件名			// 再对工作区执行情况 1 时的操作，回退到和暂存区相同版本

• 动图演示：

⭐ 6.3 add 和 commit 都被执行

• 工作区、暂存区和版本库都拥有这段被修改的内容。
  • 这种情况下，要将工作区、暂存区和版本库都回退到上个版本。

git reset --hard HEAD^ // 将工作区、暂存区和版本库都回退到版本库的上一版本内容

• 执行该操作的前提是还没有将版本库中的内容 push 到远程仓库中。
• 撤销的主要目的还是为了防止将自己写的比较挫的代码 push 到远程仓库中，如果已经 push 到远程仓库，再撤销就没有意义了。
  • 动图演示：

🌙 07. 删除文件

• 删除工作区、暂存区和版本库中的文件。
• 删除文件本质上也是在修改文件，先使用 rm 将工作区的文件删除，再用 add 将所做的修改添加到暂存区中，最后将进行的修改 commit 到版本库中，即可实现删除文件的操作。

git rm 文件名			// 1. 删除工作区和暂存区中的文件
git commit -m "message"	// 2. 将删除操作提交到版本库当中

• 现在用 git rm 将删除工作区和暂存区的操作合并，再 commit 执行的修改，只需两步即可。
  • 动图演示：

🌈 Ⅳ Git 分支管理

🌙 01. 分支介绍

• 几乎每种版本控制系统都以某种形式支持分支，一个分支代表一条独立的开发线。
• 使用分支意味着可以从开发主线上分离开来，然后在不影响主线的同时继续工作。
• 多条支线可以合并到一个主分支上来，在 git 中，主分支被称作 master。

🌙 02. 查看分支

git branch

• 查看当前本地仓库下有哪些本地分支，* 所指向的为当前工作分支。

🌙 03. 创建分支

git branch 分支名

• 新创建的分支指向当前工作分支的最新一次提交。
  • 例：使用 git branch dev 创建一个 dev 分支。

🌙 04. 切换分支

git checkout 分支名

• 将当前的工作分支从 master 分支切换到 dev 分支。
  • 动图演示：

• 可以看到，当前 * 指向了 dev 分支，表示当前工作分支变成了 dev。
• 如果在 dev 分支下对文件进行修改，master 分支是看不见的。

🌙 05. 合并分支

git merge 合并分支名	// 将指定分支合并到当前分支

• 将副分支下的代码合并到当前分支。
• 如果想将 B 分支合并到 A 分支，则必须先切换到 A 分支。

示例

1. 先使用 git checkout master 切换到 master 分支。
2. 再使用 git merge dev 将 dev 分支下的内容合并到当前的 master 分支。
   • 动图演示：

🌙 06. 删除分支

git branch -d 分支名

• 合并完成后，dev 分支就没用了，可以将 dev 分支删掉。
  • 注：不能删除当前所处分支，即处于 dev 分支时，不能删除 dev 分支。

• 切换到其他分支时，才能删除指定分支。
  • 动图演示：

🌙 07. 合并冲突

• 在实际合并分支的时候，不是一定能合并成功。
• 如果将 A、B 分支下的同一文件的同一行内容分别进行修改，因为各分支下的文件都是独立的，即两个分支下修改后的同一文件的同一行内容是不同的。因此在合并 A、B 分支时，这两个分支的同一文件的同一行内容就产生了合并冲突。

⭐ 7.1 演示合并冲突

• 当前 master 分支下的 ReadMe 文件的内容如下，接下来的演示以此 ReadMe 文件为基础。

1. 先使用 git checkout -b dev1 创建并切换到 dev1 分支。

2. 对 dev1 分支下的 ReadMe 文件的第三行进行修改。

3. 而在 dev1 分支对 ReadMe 文件的第三行进行修改时，master 分支也没闲着，也在对该文件的的第三行进行修改。

4. 此时 dev1 分支和 master 分支就在 ReadMe 文件的第三行产生了冲突，git 要合并这两条分支的话，就没办法知道合并后的第三行要保留哪个分支的内容。

⭐ 7.2 解决合并冲突

• 在发现 ReadMe 文件有冲突后，可直接查看该文件内容，git 会用 <<<<<<<，=======，>>>>>>> 来标记出不同分支的冲突内容。
  • <<<<<<< 到 ======= 中间包含的是当前分支的修改内容。
  • ======= 到 >>>>>>> 中间包含的是另一个分支 (dev1) 的修改内容。
  • <<<<<<< 和 >>>>>>> 包起来的就是该 ReadMe 文件在不同分支下的所有冲突内容。

• git 没有办法决定保留哪个分支下的内容，需要手动调整冲突代码，并再次提交修改后的结果。
• 假设需要保留 dev1 下的内容，只要在 ReadMe 文件下将其他不相关的内容删除，然后将修改后的文件提交即可。
  • 动图演示：

• 在提交之后，才算是真正的完成了本次 merge 合并分支操作。

🌙 08. bug 分支

• 假设当前正在 dev1 分支上进行开发，此时突然发现 master 分支上有 bug 需要解决。因为 master 分支是一个要求稳定的分支，不能直接对其作修改，以防出现其他更大的 bug。
• 在 git 中，每个 bug 都能通过一个新的临时分支来修复，修复后合并分支，再删除临时分支。
• 但如果 dev1 的代码在工作区中开发到一半，还无法提交，不能将 dev1 合并到 master (会将未开发完的内容合并到 master 分支)。在这个过程中突然发现在 master 分支有 bug 就麻烦了。

⭐ 8.1 存储工作区内容

git stash

• git 提供了 git stash 命令，用来储藏当前工作区信息，被储藏的内容可在将来某个时间恢复出来。
  • 现在就可以使用 git stash 命令来储藏 dev1 分支工作区的内容了。

• 此时 dev1 的工作区就是干净的，可以放心的创建分支来修复 master 的 bug。

• 在储藏好 dev1 的工作区之后，由于要基于 master 分支来修复 bug，因此要切换到 master 分支，再新拉一条临时分支来修复 bug。

• 在修复完成后，切换到 master 分支并与 fix_bug 分支合并，最后再删除 fix_bug 分支。

⭐ 8.2 恢复工作区内容

• 在修复完 master 的分支后，还要继续回到 dev1 分支继续进行开发。

• 但此时 dev1 的工作区是干净的，原先的内容被存储到了 stash 中，需要将 stash 存储的内容恢复到 dev1 的工作区中。

1. 恢复并删除 stash 文件

• 可以使用 git stash pop 命令，在恢复工作区内容的同时删除 stash 文件。

2. 恢复但不删除 stash 文件

• git stash apply：恢复工作区内容，恢复后并不会删除 stash 文件。

3. 直接删除 stash 文件

• git stash drop：删除 stash 文件，git stash pop 可以看多作是 git stash apply 和 git stash drop 的结合。

⭐ 8.3 bug 分支存在的风险

• 修复 bug 的内容并没有在 dev1 上显示，因为 master 分支是目前最新的提交，要领先于新建 dev1 时基于 master 分支的提交的，所以在 dev1 中无法看见修复 bug 的相关代码。

• 由于我们的最后目的是要让 master 合并 dev1 分支，但又因为合并时可能产生合并冲突。一旦产生合并冲突就需要人工去修改，一进行人工操作就可能在 master 分支改出 bug。

解决 bug 分支产生的合并冲突问题

1. 先将 master 分支合并到 dev1 分支，合并之后即使有合并冲突问题也可以在 dev1 分支进行修改测试，不会影响到 master 分支的内容。
2. 再将 dev1 分支合并到 master 分支，因为已经在 dev1 下解决了合并冲突问题，此次合并就无需再解决合并冲突了。

🌙 09. 删除临时分支

• 在实际开发的过程中，为了避免弄乱主分支，每添加一个新功能时，最好新建一个分支。将新建的分支称为 feature分支，在上面实现新功能的开发，合并，最后删除。
• 但如果在某个 feature 分支上开发到一般，项目被叫停，但这个 feature，还必须就地销毁，又因为该分支内容没有合并到 master 分支下，因此无法使用 git branch -d指令删除该分支。

动图演示删除分支失败的情况

使用 git branch -D 分支名 删除临时分支

• 已提交但未合并到 master 的分支只能在其他分支使用 -D 选项强制删除。

🌈 Ⅴ Git 远程操作

🌙 01. 创建远程仓库

• 目前本人使用的远程仓库是国内的 gitee，现在演示如何在 gitee 上创建仓库。

1. 在网页右上角找到 + 号，然后点击新建仓库。

2. 分别填写仓库名、路径名，选择开源，最后点击创建。
   • 注：在实际开发中，仓库名一般都是项目名。

3. 创建之后进入到如下图所示界面即创建成功。

🌙 02. 克隆远程仓库

git clone 远程仓库链接

• 克隆 / 下载远程仓库到本地，需要使⽤ git clone 命令，后⾯跟上我们的远程仓库的链接，远端仓库的链接可以从仓库中找到。
• 仓库代码选项页下有一个 克隆/下载 按钮，在弹出的界面提供了 4 种远程链接，这里主要演示最常用的 HTTPS 和 SSH 链接方式。

⭐ 2.1 使用 HTTPS 将远程仓库克隆到本地

1. 先拷贝一份远程仓库的 HTTPS 远程仓库链接。

2. 在本地的机器的任意目录下输入 git clone 刚刚拷贝过来的 HTTPS 远程仓库链接 即可。
   • 注意：git clone 操作不能在任何一个本地仓库目录下执行。

⭐ 2.2 使用 SSH 将远程仓库克隆到本地

• 直接 git clone SSH 链接是会失败的，需要先配置 SSH 公钥才行。

1. 配置 SSH 公钥

1. 依次在 gitee 个人主页点击 设置、SSH 公钥 进入以下界面。

2. 在你的用户主目录下使用 ls -al 指令查看是否存在一个 .ssh目录。

   • 存在 .ssh 目录：再查看是否存在 id_rsa 和 id_rsa.pub 这两个文件。
     • 如果 id_rsa 和 id_rsa.pub 都有则直接跳转到第 4 步。
     • 如果没有，则跳转到第 3 步。
   • 不存在 .ssh 目录：使用 mkdir .ssh 创建该目录，然后跳转到第 3 步。

3. 创建 SSH Key：在你的用户主目录下输入 ssh-keygen -t rsa -C “和你的 gitee 关联的邮箱”，然后一路回车即可。

4. 使用 cd .ssh 进入 .ssh 目录，此时再使用 cat id_rsa.pub 显示公钥内容，然后将公钥内容全部拷贝下来，再到第一步 打开的 gitee 配置公钥界面，将拷贝的内容全部粘贴然后确认即可。

2. 使用 SSH 将远程仓库克隆到本地

1. 先拷贝一份远程仓库的 SSH 远程仓库链接。

2. 在本地的机器的任意目录下输入 git clone 刚刚拷贝过来的 SSH 远程仓库链接 即可。
   • 注意：git clone 操作不能在任何一个本地仓库目录下执行。

🌙 03. 向远程仓库推送

• git 提供了两种向远程仓库推送的方式。

git push 远程主机名 本地分支名:远程分支名	// 远程主机名默认为 origin
git push 远程主机名 本地分支名				// 远程和本地分支名相同时可省略冒号后的内容

• 克隆完远程仓库后，如果在本地对该仓库的某个分支进行了修改，远程仓库是看不到这些修改的，需要进行一次 push 操作将本地仓库中的内容推送到远程仓库。
  • 注：在 push 前，要确保在该仓库下已经准备好了 name 和 email 配置项目。配置的 name 得是你自己 gitee 的用户名，email 得是你自己 gitee 的邮箱。

动图演示向远程仓库 push 推送

• 如果在克隆远程仓库时用的是 HTTPS 的方式，每次 push 都要输入 gitee 的用户名和密码。SSH 则不用。

• 在 gitee 的该仓库的 master 分支下可以看到确实推送上来了一个 file 文件。

🌙 04. 拉取远程仓库

git pull 远程主机名 远程分⽀名:本地分⽀名 // 远程主机名默认为 origin，将远程分支合并到本地分支
git pull 远程主机名 本地分支名			 // 如果远程分支与本地分支同名，可省略冒号后内容

• 如果本地仓库的内容领先于远程仓库，则需要执行 push 操作将本地仓库的内容推送到远端。
• 如果远程仓库的内容领先于本地仓库，则需要执行 pull 操作将远程仓库的内容拉取到本地。
• 如果对你的远程仓库进行了修改，就需要将远程仓库 pull 拉取到本地，不然之后无法将本地的内容 push 推送到远程仓库。

演示 pull 操作

1. 在 gitee 上对 git code 仓库的 ReadMe.en.md 文件添加一行 hello world! 文本内容。
   • 本次直接修改远程仓库为模拟，在实际工作中一定不要直接修改远程仓库。正常是通过将本地仓库的内容 push 到远端来修改远程仓库的内容。

3. 此时，远程仓库是要领先于本地仓库⼀个版本，为了使本地仓库保持最新的版本，我们需要拉取远端代码，并合并到本地。Git 提供了 git pull 命令，该命令用于从远程获取代码并合并本地的版本。

🌈 Ⅵ Git 标签管理

• 在 gitee 中标签 tag 是对某次 commit 的⼀个标识，相当于起了⼀个别名。
  • 例如：在项目发布某个版本的时候，针对最后⼀次 commit 起⼀个== v1.0 ==这样的标签来表示这是发布的第一个版本。
• 相较于难以记住的 commit id ， gitee 的 tag 就很好的解决这个问题，因为 tag ⼀定要给⼀个让人容易记住，且有意义的名字。当我们需要回退到某个重要版本时，直接使用标签就能很快定位到。

🌙 01. 创建标签

• 打标签操作是针对某一次的提交 commit 进行的。

1. 打标签

1. 切换到需要打标签的分支上。
2. 使用 git tag 标签名 指令创建一个新标签。
3. 默认标签是打在最新提交的 commit 上的，只要 commit 一下就能打上刚刚创建的标签了。

2. 查看标签

git tag	// 用来查看存在哪些标签

🌙 02. 删除本地标签

git tag -d 标签名

• 如果打错了标签，git 也是支持删除标签的。

🌙 03. 推送标签至远程

• 在本地创建的标签都只存储在本地，不会自动推送到远程。因此，打错的标签可以放心的在本地进行删除。

1. 推送 单个 标签

git push origin 标签名	// 推送指定标签至远端

• 将 v1.0 标签推送至远程仓库，然后就能看到 gitee 的远程仓库多了个 v1.0 标签了。

2. 推送 全部 标签

• 如果本地有很多标签的话，也可以一次性全部推送到远端。

git push origin --tages	// 推送全部标签至远端

🌙 04. 删除远程标签

• 如果标签已经被推送至远程，由于不能直接修改远程仓库，所以删除标签就稍微麻烦一点。

删除远程标签步骤

1. 先在本地使用 git tag -d 标签名 删除指定标签。
2. 然后使用 git push origin :标签名 将所作的删除操作推送至远端。