关于git的基本操作

---

前言

提示：如果查看日志后无法返回，按 'q' 键

举例说明关于git一些容易忽视的最基本的细节操作。

---

1、新建本地仓库

1.1 新建文件夹 git_test

在D盘新建文件夹 git_test

1.2 打开命令窗口并且切换到 git_test 目录下

两种方法：

1.2.1 直接在git_test 目录下打开命令窗口

1.2.2.先打开命令窗口再使用cd命令切换进去

比如我先在f盘打开了命令窗口，再使用 cd /d/git_test 命令切换到了 d 盘的 git_test 文件夹下。

以上是 linux 的切换方法，实际上在windows下也可以用，在windows下还可以用 cd d:\git_test 命令

1.3 生成仓库

使用 git init 命令后，在文件夹下生成了一个 .git 文件夹，表示仓库建立好了。

2、编写文件

2.1 新建两个文件 t1 t2

命令 touch t1 t2
(mkdir 是新建文件夹)

touch t1 t2

2.2 查看状态

git status

1）On branch master
表示当前位于名为"master"的分支上

2）No commits yet
尚未进行提交：这意味着在您的本地仓库中还没有进行过任何提交。

3）Untracked files: （未跟踪的文件）
(use “git add …” to include in what will be committed)
t1
t2
工作目录中存在未被Git跟踪的文件。 分别为t1 t2 文件
Git会自动跟踪已经被Git管理的文件，但对于新添加的文件（或之前未被跟踪的文件），您需要使用"git add"命令将它们添加到Git的跟踪列表中。

4）nothing added to commit but untracked files present (use “git add” to track)
这句话的意思是当前没有要提交的更改，但存在未跟踪的文件。它向您提供了解决这种情况的建议，即使用"git add"命令来跟踪（即将其加入版本控制）这些未跟踪的文件。
在Git中，跟踪文件是指将文件添加到Git的版本控制中，以便将其纳入后续的提交中。要跟踪文件，您可以使用以下命令：
git add

2.3 添加跟踪

2.3.1 添加跟踪

git add <file>

如果想要添加跟踪所有文件

git add *

这样就将文件"t1"和"t2"添加到了Git的暂存区（即将它们提交的准备区域）。
这些文件将成为下一次提交的一部分。

2.3.2 添加跟踪后再次查看状态

这句话的意思是：
您当前位于"master"分支。
您还没有进行过任何提交。
存在即将提交的更改。
要提交的更改包括两个新文件：“t1"和"t2”。

2.3.3 修改文件

我们修改文件 t1 (在t1文件里面加上内容 “c1”)

可以看到 t1 文件的内容已经修改为"c1"
再次查看状态：

这句话的意思是：
1.您当前位于"master"分支。
2.您还没有进行过任何提交。
3.有即将提交的更改。
"t1"和"t2"是新文件，将被包含在下一次提交中。
4.有未暂存的更改。
"t1"文件被修改但尚未暂存，不会被包含在下一次提交中。

这意味着您已经使用了"git add"命令将文件"t1"和"t2"添加到了Git的暂存区，准备进行下一次提交。
但是，"t1"文件的修改尚未被暂存，仍然处于未暂存的状态。

1）修改后的文件添加到暂存区

如果您希望将"t1"文件的修改包含在下一次提交中，可以使用命令"git add t1"将其暂存。这样，修改将被添加到暂存区，并在下一次提交时包括。

2）丢弃对 t1 文件的修改

另一方面，如果您希望丢弃对"t1"文件的修改，可以使用命令"git restore t1"。这将撤销对文件的更改，并将其还原为最后一次提交的状态。

git restore t1

可以看到 git restore t1 操作后 t1 文件里面的内容撤销了。

2.4 提交

2.4.1 修改 t1 内容

我们还是先修改 t1 的内容为 “c1”, 然后 使用

git add t1

添加到了Git的暂存区。
然后再查看其状态：

说明：此时可以使用

git rm --cached t1

将 t1 文件移出 Git的暂存区：

如图，已经将 t1 文件移出暂存区了。

2.4.2 提交

首先，我们还是先用 git add t1 将文件添加到 Git的暂存区。
使用以下命令提交：

git commit -m "t1 c1"

查看状态

2.5 多次提交后查看

2.5.1 多次提交

我们将 t1 修改了四个版本，并且进行了4次提交：

1）第1次提交信息：“t1 c1”

c1

2）第2次提交信息：“t1 c2”

c1
c2

3）第3次提交信息：“t1 c3”

c1
c2
c3

4）第4次提交信息：“t1 c4”

c1
c2
c3
c4

2.5.2 查看提交历史

1）git log

显示完整的提交历史记录：

git log

2）git log --oneline

要查看当前所在的版本，可以使用以下命令：

git log --oneline

显示每个提交的简洁摘要信息（提交哈希值、作者、日期和提交消息）：

3）git log --graph

以图形化的方式显示提交历史记录（使用 ASCII 字符绘制图形）：

git log --graph

4）git reflog

用于查看 Git 引用日志，以及各种最详细操作。

git reflog

说明：如果查看日志后无法返回，按 'q' 键

3、版本回退

版本回退有两种方法：
git reset --hard HEAD^
git revert --hard HEAD^

如果已经有A -> B -> C，想回到B：
方法一：reset到B，丢失C：
A -> B
方法二：再提交一个revert反向修改，变成B：
A -> B -> C -> B
C还在，但是两个B是重复的
看你的需求，也许C就是瞎提交错了（比如把密码提交上去了），必须reset
如果C就是修改，现在又要改回来，将来可能再改成C，那你就revert

3.1 git reset

使用命令：

git reset --hard HEAD^

可以看到版本回退到了上一个版本C1


已经回退到了 4ed4caf 版本了。

如果回退到C1版本之后想要再次回到C2版本：

git reset --hard C2

已经恢复到了 8f90911 版本了。

3.2 git revert

使用命令：

git revert --hard HEAD^

将会建立一个 C1’（为C1的副本） 并且main分支会指向它

举例：
有这么一个分支

使用命令：

git revert --hard HEAD^

建立了一个 C5’（为C5的副本） 并且main分支指向了它

4、查看历史版本

如果我想看看以前的版本，只是想看看，并不想修改保存，那么我们需要用到 HEAD分离。

4.1 HEAD分离（示意图说明）

如图，HEAD 指向 main， main 指向 C1 （所以main分支上面有个星号）
现在我们将 HEAD 直接指向 C1（这样 HEAD也就跟main分支分开了，也就是HEAD分离）
使用命令：

git checkout C1     新版本的git 推荐使用 git switch C1

从图中可以看到 HEAD 与 main分支分离了：
① HEAD不再指向main分支，而是指向了C1这个提交
② main旁边的星号消失了
此时再操作命令都是在HEAD指向的基础上操作的，如果我们此时使用 git commit 提交，将会新增一个C2提交，并且C2不属于任何分支（一般这种不属于任何分支的节点我们不用管它）

如图：
1.我们先使用 git checkout C2 使HEAD分离（使得HEAD指向了C2提交节点）
2.然后使用 git commit提交一次，产生C8（C8不属于任何分支，一般不做管理，只是用来中途返回查看修改测试前面的程序）
3.测试完毕后直接 使用 git checkout main 回到原来的分支（此时HEAD自动又指向main了）

补充说明：
如果我们想要对 上图中的 C8节点进行管理，就可以 在HEAD指向C8的时候建一个分支，比如我可以用 git branch test1 新建一个test1的分支，再使用 git checkout test1 切换到 test1分支对其维护管理，也可以用一条指令代替上面两条指令：

git checkout -b test1

新版本的git推荐用 switch ,与下面等价：
git switch -c test1

新建 test1 分支，并且切换指向 test1

如果我们不需要对 C8节点管理就不用建分支了，用完直接切换回主分支就好了

注意：如果修改后，直接切换回主分支会出错，你需要先放弃修改，如何放弃修改？使用：

git reset --hard HEAD  
git checkout master

第一条命令将重置工作目录和暂存区到最近的提交，丢弃所有未提交的更改。然后，您可以切换到master分支。

4.2 HEAD分离（实例说明）

4.2.1 提交记录

如图可以看出，ti文件提交了4次，目前 HEAD指向master分支，master指向 a43b58f

4.2.2 HEAD分离

使用 git checkout HEAD^^ 指令直接让 HEAD 指向了 64748be （使用 git checkout 64748be 效果相同）

这些信息是提示你现在处于 HEAD 分离的状态，您可以进行实验性的更改和提交，但是这些更改不会影响任何分支。
如果您想保留所做的更改，可以创建一个新的分支来保存这些提交，使用 git switch -c 命令创建新分支
如果您不想保留在 HEAD 分离 状态下所做的更改，可以使用 git switch - 命令回到之前的分支

此时文件内容对应 64748be 时里面的内容，同时红框中的也不再是分支名称了，而是HEAD指向的提交哈希值。

上图可以看到 HEAD 指向 64748be

4.2.3 新建分支test1并且切换到分支

在目前HEAD所在位置直接新建分支

如图，我们用 git branch test1 命令新建了 test1分支（但是此时仍然处于HEAD分离的状态）
图中 HEAD 和 test1分支同时指向 64748be
我们再用 git checkout test1 命令切换到test1分支：

可以看到 HEAD -> test1 表示HEAD指向了test1，test1指向了 64748be（此时不再是HEAD分离的状态了），后面括号里面也只想了test1分支

4.2.4 修改提交

我们修改t1的内容：新增一行 “test1 -1” 并且提交 git commit -m "test1 -1"

5、合并

5.1 git merge

5.1.1 图示说明

将 bugFix 合并到 main 里，目前我们处于 main 分支，只需要：

git merge bugFix 

5.1.2 实例说明

5.1.2.1 master分支

1）第1次提交 git commit -m “master -t1”
新建一个文件 t1，其中内容为：

12345

2）第2次提交 git commit -m “master -t2”
再新建一个文件 t2，其中内容为：

1
2
3
4
5
6
7
8

5.1.2.2 test分支

1）先HEAD分离，使得HEAD指向 9cfe647
git checkout 9cfe647

HEAD 指向了 9cfe647
2）新建 test 分支并且切换到test分支
git checkout -b test

此时工作区只有 t1 文件，并且其内容和master分支的t1文件夹内容一样

3）新建 t2 文件
新建t2文件，其中内容为：

1
2
a
b
c
d
6
7
8

然后 提交，git commit -m "test t2"

5.1.2.3 将master分支合并到test分支

因为目前处于 test分支下面，直接 git merge master

提示合并出现了冲突，冲突主要是在 t2 文件（因为t2文件在master分支和test分支有冲突的地方）
解决冲突的步骤：
1）执行 git status 命令，查看冲突的文件列表。
2）使用文本编辑器打开包含冲突的文件 t2。

手动更改下这些冲突就可以了
3）改完之后保存，再提交
git add t1 t2
git commit -m "合并"

注意，如果碰到冲突你此时不想合并了，可以使用以下命令取消合并
git merge --abort

5.2 git rebase

参考：
https://learngitbranching.js.org/?locale=zh_CN
https://www.liaoxuefeng.com/wiki/896043488029600