Git 之光速入门系列-中

Git 之光速入门系列

前言

Git 是开发过程中非常重要的一个工具，几乎是所有开发工作必须的，在本科阶段一知半解的，即使有 Git 的使用场景也没有深入去学习过。

看了许多 Git 教程和资料之后，在这里做个整理，提炼出最核心的原理，帮助你快速入门 Git。

但 Git 总归是个工具，需要动手实践才能快速掌握，建议所有学 Git 的都自己做个小实验，走一遍流程。

本系列文章的案例都是在 Windows 环境下运行的，需要安装 Git

版本管理的引路人：HEAD 指针

在这篇文章中，我们会涉及到一个新概念：HEAD 指针

HEAD 直观上可以理解为我们当前所使用的仓库版本，而仓库版本，实际上就是 Commit，我们 Commit 了一个修改，仓库就推进了一个版本，管理版本，实际上就是管理 Commit，而 HEAD 仅仅是指向某一个 Commit 的指针。

上一篇文章出现过的 HEAD -> master 的意思就是当前的 HEAD 指针指向 master 分支，即目前处于 master 分支中，关于分支，后续会再进行解释。

万物皆可反悔：撤销修改

命令	功能
git checkout	撤销修改
git reset	版本回退

撤销工作区修改：此时修改还在工作区中，即在本地环境的修改，没有进行任何提交操作，如果我们修改的内容比较多，我们想要 Git 帮我们一键还原到仓库的版本，就可以使用以下的操作

1. 查看文件修改（可选）
PS C:\git> git diff
diff --git a/README.md b/README.md
index caaaaf4..20eefa1 100644
--- a/README.md
+++ b/README.md
@@ -1,2 +1,3 @@
 ## Welcome to git
 我对文件进行了修改
+我加了一条想撤回的信息

2. 撤销工作区修改
PS C:\git> git checkout -- README.md
PS C:\git> git diff
PS C:\git>

查看文件修改：git diff
我们可以看到，我们对文件进行了修改，但此时没有提交到暂存区，也没有进行过 Commit 操作
撤销工作区修改：git checkout -- <filename>
我们取消指定文件的修改，还原到仓库内的版本。也可以多文件还原，具体操作可以查阅相关文档，本文就不举例了

撤销暂存区修改：此时修改已经从工作区提交到暂存区了，但还没进行 Commit

1. 查看文件修改（可选）
PS C:\git> git diff
diff --git a/README.md b/README.md
index caaaaf4..20eefa1 100644
--- a/README.md
+++ b/README.md
@@ -1,2 +1,3 @@
 ## Welcome to git
 我对文件进行了修改
+我加了一条想撤回的信息

2. 提交修改至暂存区
PS C:\git> git add README.md

3. 查看状态（可选）
PS C:\git> git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   README.md

4. 回退版本
PS C:\git> git reset HEAD README.md
Unstaged changes after reset:
M       README.md

5. 查看状态（可选）
PS C:\git> 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.md

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

6. 查看文件修改（可选）
PS C:\git> git diff
diff --git a/README.md b/README.md
index caaaaf4..20eefa1 100644
--- a/README.md
+++ b/README.md
@@ -1,2 +1,3 @@
 ## Welcome to git
 我对文件进行了修改
+我加了一条想撤回的信息

7. 撤销工作区修改
PS C:\git> git checkout -- README.md

8. 查看文件修改（可选）
PS C:\git> git diff
PS C:\git>

查看文件修改：git diff
提交修改至暂存区：git add <filename>
查看状态：git status
此时状态信息告诉我们，修改还没进行过 Commit
回退版本：git reset HEAD <filename>，回退某文件至当前 HEAD 指针所指向的仓库版本
此时就撤销了暂存区的修改，但工作区（本地环境）的修改还没有撤销
查看状态：git status
可以看到存在未提交的修改，证实工作区并没有还原
查看文件修改：git diff
证实工作区并没有还原
撤销工作区修改：git checkout -- <filename>
查看文件修改：git diff
现在可以看到，工作区（本地）的修改也被还原了

版本回退：现在我们的修改已经 Commit 至仓库了，假设此时发现代码有 Bug，想回退至原来的版本

1. 查看仓库日志（可选）
PS C:\git> git log
commit d339fcd86cfb3034221ff97d20a51f780dad3e65 (HEAD -> master)
Author: SyanLin <475694569@qq.com>
Date:   Wed Jul 13 18:23:28 2022 +0800

    Version 2.0 with Bug

commit fcdd13e9b08d205dcfaea412d597c11697932072
Author: SyanLin <475694569@qq.com>
Date:   Wed Jul 13 18:23:12 2022 +0800

    Version 1.0

2. 版本回退
PS C:\Users\china\Desktop\git> git reset --hard HEAD^
HEAD is now at fcdd13e Version 1.0

3. 查看仓库日志（可选）
PS C:\Users\china\Desktop\git> git log
commit fcdd13e9b08d205dcfaea412d597c11697932072 (HEAD -> master)
Author: SyanLin <475694569@qq.com>
Date:   Wed Jul 13 18:23:12 2022 +0800

    Version 1.0

查看仓库日志：git log
现在有两个版本，目前是 Version 2.0，想回退至 Version 1.0
版本回退：git reset --hard HEAD^，这个指令有很多参数，具体还是得看文档。这里的 --hard 表示回退 HEAD 指针、暂存区和工作区，而 HEAD^ 表示回退一个版本，即回退至上一个 Commit，如果是 HEAD^^ 则是两个版本
查看仓库日志：git log
可以看到，Commit 记录中已经没有 Version 2.0 了，就好像它从来没有出现过一样。但可能你突然发现 Version 2.0 的 Bug 很好解决，我又不想撤回了，怎么办？其实是有办法解决的，具体本文就不涉及了，有兴趣的可以进行阅读 Git 教程廖雪峰。

代码世界的平行宇宙：分支

终于到了激动人心的分支环节了，另一个 Git 最为强大的核心功能

但是我们首先得知道什么是分支，为什么需要分支，在之前的各种信息中，你可能会注意到 master 或 branch 之类的词，master 的意思是主分支，仓库默认的分支。

假如在团队协作中，代码写了一半，程序还无法运行，该 Commit 吗。Commit 了，别人无法运行程序进行自己的开发任务，不 Commit 吧，自己万一丢失了工作进度怎么办，所以这时候就需要分支了。

另一方面，在开发中，我们的代码可能会处于多种状态，例如开发、修 Bug 和发布状态，一个长期维护的代码，肯定会不断经历这些状态的切换。如果没有 Git，状态越多就越容易混乱，例如修一个 Bug，它既得同步到发布代码中，又得同步到当前开发的代码中，手动管理这些代码非常困难，特别是在多人协作中，有时候哪个文件是哪个版本哪个状态，自己也搞不清楚了。

如标题所写的：平行宇宙，分支实际上就是在某个时间节点复制一份仓库出来，自己做的修改都是基于这个复制的仓库，这个复制的仓库就是分支。

在第一个场景中，我们每个人可以有自己的 dev 开发分支，所有人都可以在自己的开发分支上进行 Commit，不会影响到主分支，而当我们工作完成后，就可以对分支进行合并，将我们的工作合并到主分支上。

在第二个场景中，我们可以有一个 release 发行分支、dev 开发分支和 bug 修复分支。在团队写作中，修 Bug 的成员只要将 bug 分支合并到 release 分支完成 Bug 修复就行了，而开发分支 dev 只要同步 bug 分支中的 Commit，即可在自己的这个分支（版本）也修复 Bug。

说了这么多，其实就是帮助大家理解分支的作用，下面我们就进入实操吧！

命令	功能
git switch	切换分支
git branch	分支相关命令
git merge	合并分支

创建、合并和删除分支：

1. 创建并切换到dev分支
PS C:\git> git switch -c dev
Switched to a new branch 'dev'

2. 查看分支信息（可选）
PS C:\git> git branch
* dev
  master

3. 提交修改至暂存区
PS C:\git> git add README.md

4. 提交修改
PS C:\git> git commit -m 'Dev Commit'
[dev e9c95d8] Dev Commit
 1 file changed, 3 insertions(+)

5. 查看仓库日志（可选）
PS C:\git> git log
commit e9c95d8650881644afea857bcfc64d8e2bb8a695 (HEAD -> dev)
Author: SyanLin <475694569@qq.com>
Date:   Wed Jul 20 22:03:19 2022 +0800

    Dev Commit

commit b9ccd8c12491fc62800773a67f46f25aa2db6c6d (master)
Author: SyanLin <475694569@qq.com>
Date:   Wed Jul 13 14:28:52 2022 +0800

    Update README.md

...

6. 切换回主分支
PS C:\git> git switch master
Switched to branch 'master'

7. 查看分支信息（可选）
PS C:\git> git branch
  dev
* master

8. 查看仓库日志（可选）
PS C:\git> git log
commit b9ccd8c12491fc62800773a67f46f25aa2db6c6d
Author: SyanLin <475694569@qq.com>
Date:   Wed Jul 13 14:28:52 2022 +0800

    Update README.md
    
9. 合并分支
PS C:\git> git merge dev
Updating b9ccd8c..e9c95d8
Fast-forward
 README.md | 3 +++
 1 file changed, 3 insertions(+)

10. 查看仓库日志（可选）
PS C:\git> git log
commit e9c95d8650881644afea857bcfc64d8e2bb8a695 (HEAD -> master, dev)
Author: SyanLin <475694569@qq.com>
Date:   Wed Jul 20 22:03:19 2022 +0800

    Dev Commit

commit b9ccd8c12491fc62800773a67f46f25aa2db6c6d
Author: SyanLin <475694569@qq.com>
Date:   Wed Jul 13 14:28:52 2022 +0800

    Update README.md

11. 删除dev分支
PS C:\git> git branch -d dev
Deleted branch dev (was e9c95d8).

12. 查看分支信息（可选）
PS C:\git> git branch
* master

创建并切换到 dev 分支：git switch -c dev，-c 是创建分支的意思
查看分支信息：git branch
可以看到现在有两个分支，* 代表我们现在所在的分支
提交修改至暂存区：此时我们的修改是在分支 dev 上
提交修改
查看仓库日志：可以看到 HEAD -> dev，表示这个 Commit 是在 dev 分支上
切换回主分支：git switch <name>
查看分支信息：可以看到，目前我们在主分支上
查看仓库日志：我们在 dev 分支上的修改，在主分支中没有任何显示
合并分支：git merge <name>
我们在主分支上合并 dev 分支
查看仓库日志：可以看到，现在 Commit 已经同步到主分支上了，已经能看到 Commit 了
删除 dev 分支：git branch -d <name>，-d 代表删除
这时 dev 分支就不需要了，在需要的时候再进行创建即可
查看分支信息：现在仓库就只有一个主分支了

解决冲突：在合并的过程中，会出现两个分支对同一内容进行了修改，而 Git 无法判断哪一个修改需要保留，就会报冲突，让我们手动解决这些冲突

此时dev分支已经进行了修改和Commit的操作，现在是在主分支上进行修改

1. 添加修改至暂存区
PS C:\git> git add README.md

2. 提交修改
PS C:\git> git commit -m 'Master Commit'
[master 8cdc98d] Master Commit
 1 file changed, 1 insertion(+), 1 deletion(-)

3. 合并分支
PS C:\Users\china\Desktop\git> git merge dev
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.

4. 查看仓库状态（可选）
PS C:\Users\china\Desktop\git> 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.md

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

5. 查看并修改文件
...
<<<<<<< HEAD
分支冲突：哈哈哈
=======
这是冲突：嘿嘿嘿
>>>>>>> dev
...

6. 添加修改至暂存区
PS C:\git> git add README.md

7. 提交修改
PS C:\git> git commit -m 'Fix Conflict'
[master 009c01f] Master Commit

添加修改至暂存区
提交修改
合并分支：对分支进行合并后，看到系统告诉我们存在冲突，让我们修复冲突之后再 Commit
查看仓库状态：此时仓库状态会告诉我们冲突发生在哪个文件
查看并修改文件：打开文件后，会发现有一部分内容被加上了额外的标记信息，<<<<<HEAD 到 ====== 间是 HEAD 版本，也就是当前分支的版本，而另一部分就是 dev 分支的版本，我们需要手动选择保留哪一种修改，删去另一个即可
添加修改至暂存区：完成上述操作后，再进行一次提交，即可修复冲突
提交修改

到目前为止，我们几乎已经学会了 Git 的底层使用逻辑，但是目前都基于本地运行，下一节，我们会进入 Git 入门的最后一站，在网络中使用 Git！

文章作者: Yuan.

文章链接: /archives/git2

微信扫一扫

评论 | 0条评论

前言

目录

版本管理的引路人：HEAD 指针

万物皆可反悔：撤销修改

代码世界的平行宇宙：分支