【Linux】：git基本操作_添加文件_两种场景_查看.git文件 || git修改文件 || 版本回退

🎯添加⽂件–场景⼀

🎯在包含.git的⽬录下新建⼀个ReadMe⽂件，我们可以使⽤ git add 命令可以将⽂件添加到暂存区：
• 添加⼀个或多个⽂件到暂存区： git add [file1] [file2] …
• 添加指定⽬录到暂存区，包括⼦⽬录： git add [dir]
• 添加当前⽬录下的所有⽂件改动到暂存区： git add .
再使⽤ git commit 命令将暂存区内容添加到本地仓库中：
• 提交暂存区全部内容到本地仓库中: git commit -m “message”
• 提交暂存区的指定⽂件到仓库区： git commit [file1] [file2] … -m “message”
注意 git commit 后⾯的 -m 选项，要跟上描述本次提交的message，由⽤⼾⾃⼰完成，这部分内容绝对不能省略，并要好好描述，是⽤来记录你的提交细节，是给我们⼈看的
🎯例如：

[root@VM-4-7-centos ~]# cat ReadMe
#include
int main()
{
    printf("hello git");
    return 0;
}
[root@VM-4-7-centos ~]# git add ReadMe
[root@VM-4-7-centos ~]# git commit -m "add first file"
[master (root-commit) a358dce] add first file
 1 file changed, 6 insertions(+)
 create mode 100644 ReadMe
1
2
3
4
5
6
7
8
9
10
11
12

[root@VM-4-7-centos ~]# cat ReadMe
#include
int main()
{
    printf("hello git");
    return 0;
}
[root@VM-4-7-centos ~]# git add ReadMe
[root@VM-4-7-centos ~]# git commit -m "add first file"
[master (root-commit) a358dce] add first file
 1 file changed, 6 insertions(+)
 create mode 100644 ReadMe
[root@VM-4-7-centos ~]# 
1
2
3
4
5
6
7
8
9
10
11
12
13

hyb@139-159-150-152:~/gitcode$ vim ReadMe
hyb@139-159-150-152:~/gitcode$ cat ReadMe
hello bit
hello bit
hyb@139-159-150-152:~/gitcode$ git add ReadMe
hyb@139-159-150-152:~/gitcode$ git commit -m "commit my first file"
[master (root-commit) c614289] commit my first file
1 file changed, 2 insertions(+)
create mode 100644 ReadMe
1
2
3
4
5
6
7
8
9

git commit 命令执⾏成功后会告诉我们，1个⽂件被改动（就是我们新添加的ReadMe⽂件），插⼊了两⾏内容（ReadMe有两⾏内容）
我们还可以多次add不同的⽂件，⽽只commit⼀次便可以提交所有⽂件，是因为需要提交的⽂件是通通被add到暂存区中，然后⼀次性commit暂存区的所有修改。如：

hyb@139-159-150-152:~/gitcode$ touch file1 file2 file3
hyb@139-159-150-152:~/gitcode$ git add file1
hyb@139-159-150-152:~/gitcode$ git add file2
hyb@139-159-150-152:~/gitcode$ git add file3
hyb@139-159-150-152:~/gitcode$ git commit -m "add 3 files"
[master 23807c5] add 3 files
3 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 file1
create mode 100644 file2
create mode 100644 file3
1
2
3
4
5
6
7
8
9
10

截⾄⽬前为⽌，我们已经更够将代码直接提交⾄本地仓库了。我们可以使⽤ git log 命令，来查看下历史提交记录：

[root@VM-4-7-centos ~]# git add ReadMe
[root@VM-4-7-centos ~]# git commit -m "add first file"
[master (root-commit) a358dce] add first file
 1 file changed, 6 insertions(+)
 create mode 100644 ReadMe
[root@VM-4-7-centos ~]# ^C
[root@VM-4-7-centos ~]# clear
[root@VM-4-7-centos ~]# git log 
commit a358dceff752b9fb00a7ad0f047e0edf3e6fb6d2
Author: FJJ <2397194209@qq.com>
Date:   Wed Nov 8 18:53:26 2023 +0800

    add first file
[root@VM-4-7-centos ~]# git log
commit a358dceff752b9fb00a7ad0f047e0edf3e6fb6d2
Author: FJJ <2397194209@qq.com>
Date:   Wed Nov 8 18:53:26 2023 +0800
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

该命令显⽰从最近到最远的提交⽇志，并且可以看到我们commit时的⽇志消息
如果嫌输出信息太多，看得眼花缭乱的，可以试试加上 --pretty=oneline 参数：

[root@VM-4-7-centos ~]# git log --pretty=oneline
1

需要说明的是，我们看到的⼀⼤串类似 23807c5…56eed6 的是每次提交的 commit id （版本号），Git的 commit id 不是1，2，3……递增的数字，⽽是⼀个SHA1计算出来的⼀个⾮常⼤的数字，⽤⼗六进制表⽰（你看到的 commit id 和我的肯定不⼀样，以你⾃⼰的为准）
查看.git⽂件
先来看看我们的 .git 的⽬录结构

.git/
├── branches
├── COMMIT_EDITMSG
├── config
├── description
├── HEAD
├── hooks
│ ├── applypatch-msg.sample
│ ├── commit-msg.sample
│ ├── fsmonitor-watchman.sample
│ ├── post-update.sample
│ ├── pre-applypatch.sample
│ ├── pre-commit.sample
│ ├── pre-merge-commit.sample
│ ├── prepare-commit-msg.sample
│ ├── pre-push.sample
│ ├── pre-rebase.sample
│ ├── pre-receive.sample
│ └── update.sample
├── index
├── info
│ └── exclude
├── logs
│ ├── HEAD
│ └── refs
│ └── heads
│ └── master
├── objects
│ ├── 23
│ │ └── 807c536969cd886c4fb624b997ca575756eed6
│ ├── 83
│ │ └── 0a8c9feefbdc098bbae2cdc25e5034ce1920d7
│ ├── 8f
│ │ └── add50161b6fafa53ce7e79d278dc490240c946
│ ├── 9c
│ │ └── 9e1f0f6bff3015df71a0963004476f5e6cfd54
│ ├── c6
│ │ └── 1428926f3853d4ec6dde904415b0e6c1dabcc6
│ ├── e6
│ │ └── 9de29bb2d1d6434b8b29ae775ad8c2e48c5391
│ ├── info
│ └── pack
└── refs
├── heads
│ └── master
└── tags
18 directories, 27 files
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

index 就是我们的暂存区，add后的内容都是添加到这⾥的
HEAD 就是我们的默认指向master分⽀的指针
⽽默认的 master 分⽀，其实就是
打印的 23807c536969cd886c4fb624b997ca575756eed6 是什么东西呢？保存的就是当前最新的 commit id
3. objects 为Git的对象库，⾥⾯包含了创建的各种版本库对象及内容。当执⾏ git add 命令时，暂存区的⽬录树被更新，同时⼯作区修改（或新增）的⽂件内容被写⼊到对象库中的⼀个新的对象中，就位于".git/objects"⽬录下，让我们来看看这些对象有何⽤处：
总结⼀下，在本地的git仓库中，有⼏个⽂件或者⽬录很特殊
• index:暂存区， git add 后会更新该内容。
• HEAD:默认指向master分⽀的⼀个指针。
• refs/heads/master:⽂件⾥保存当前 master 分⽀的最新 commit id 。
• objects:包含了创建的各种版本库对象及内容，可以简单理解为放了git维护的所有修改
后⾯再学习过程中，最好能将常⻅的 git 操作与 .git ⽬录当中的结构内容变化对应起来，这样有利于我们理解git细节流程。我们后⾯还会学习什么分⽀，标签什么的，那我想后⾯同学就应该学习对应着研究了！

🎯添加⽂件–场景⼆

学习到这⾥，我们已经清楚了如何向仓库中添加⽂件，并且对于⼯作区、暂存区、版本库也有了⼀定的认识。那么我们再展⽰⼀种添加⽂件的场景，能加深对⼯作区、暂存区、版本库的理解，⽰例如下

~/gitcode$ touch file4 #1. 新增file4⽂件
~/gitcode$ git add file4 #2. 将file4添加到暂存区
~/gitcode$ touch file5 #3. 新增file5⽂件
~/gitcode$ git commit -m"add file" #4. 提交修改
[master 3d406c0] add file
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 file4
1
2
3
4
5
6
7

提交后发现打印了 1 file changed, 0 insertions(+), 0 deletions(-) ，意思是只有⼀个⽂件改变了，这时我们提出了疑问，不是新增了两个⽂件吗？
再来回忆下， git add 是将⽂件添加到暂存区， git commit 是将暂存区的内容添加到本地仓库中。由于我们并没有使⽤ git add file5 ，file5就不在暂存区中维护，所以我们commit的时候 其实只是把已经在暂存区的file4提交了，⽽遗漏了⼯作区的file5。如何提交file5呢？很简单，再次add , commit 即可

🎯修改⽂件

Git⽐其他版本控制系统设计得优秀，因为Git跟踪并管理的是修改，⽽⾮⽂件
什么是修改？⽐如你新增了⼀⾏，这就是⼀个修改，删除了⼀⾏，也是⼀个修改，更改了某些字符，也是⼀个修改，删了⼀些⼜加了⼀些，也是⼀个修改，甚⾄创建⼀个新⽂件，也算⼀个修改
让我们将ReadMe⽂件进⾏⼀次修改

~/gitcode$ cat ReadMe
hello bit
hello git
hello world
1
2
3
4

此时，仓库中的ReadMe和我们⼯作区的ReadMe是不同的，如何查看当前仓库的状态呢？ git status 命令⽤于查看在你上次提交之后是否有对⽂件进⾏再次修改

~/gitcode$ git status
On branch master
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git restore ..." to discard changes in working directory)
modified: ReadMe
no changes added to commit (use "git add" and/or "git commit -a")
1
2
3
4
5
6
7

上⾯的结果告诉我们，ReadMe被修改过了，但还没有完成添加与提交
⽬前，我们只知道⽂件被修改了，如果能知道具体哪些地⽅被修改了，就更好了。有同学会说，我刚改的我知道呀！可是，你还记得你三天前写了什么代码吗？或者没写？

~/gitcode$ git diff ReadMe
diff --git a/ReadMe b/ReadMe
index 9c9e1f0..4a97140 100644
--- a/ReadMe
+++ b/ReadMe
@@ -1,2 +1,3 @@
hello bit
-hello bit
+hello git
+hello world
1
2
3
4
5
6
7
8
9
10

git diff [file] 命令⽤来显⽰暂存区和⼯作区⽂件的差异，显⽰的格式正是Unix通⽤的diff格式 也可以使⽤ git diff HEAD – [file] 命令来查看版本库和⼯作区⽂件的区别
知道了对ReadMe做了什么修改后，再把它提交到本地仓库就放⼼多了

~/gitcode$ git add ReadMe
~/gitcode$ git status
On branch master
Changes to be committed:
(use "git restore --staged ..." to unstage)
modified: ReadMe
1
2
3
4
5
6

git add 之后，就没有看到上⾯ no changes added to commit (use "git add"and/or “git commit -a”) 的消息了。接下来让我们继续 git commit 即可：

~/gitcode$ git commit -m "add modify ReadMe file"
[master 94da695] add modify ReadMe file
1 file changed, 2 insertions(+), 1 deletion(-)
~/gitcode$ git status
On branch master
nothing to commit, working tree clean
1
2
3
4
5
6

🎯版本回退

之前我们也提到过，Git能够管理⽂件的历史版本，这也是版本控制器重要的能⼒。如果有⼀天你发现之前前的⼯作做的出现了很⼤的问题，需要在某个特定的历史版本重新开始，这个时候，就需要版本回退的功能了
执⾏ git reset 命令⽤于回退版本，可以指定退回某⼀次提交的版本。要解释⼀下“回退”本质是要将版本库中的内容进⾏回退，⼯作区或暂存区是否回退由命令参数决定：
git reset 命令语法格式为： git reset [–soft | --mixed | --hard] [HEAD]
• --mixed 为默认选项，使⽤时可以不⽤带该参数。该参数将暂存区的内容退回为指定提交版本内容，⼯作区⽂件保持不变。
• --soft 参数对于⼯作区和暂存区的内容都不变，只是将版本库回退到某个指定版本。
• --hard 参数将暂存区与⼯作区都退回到指定版本。切记⼯作区有未提交的代码时不要⽤这个命令，因为⼯作区会回滚，你没有提交的代码就再也找不回了，所以使⽤该参数前⼀定要慎重
• HEAD 说明：
◦ 可直接写成commit id，表⽰指定退回的版本
◦ HEAD表⽰当前版本
◦ HEAD^上⼀个版本
◦ HEAD^^上上⼀个版本
◦ 以此类推…
• 可以使⽤〜数字表⽰
◦ HEAD~0表⽰当前版本
◦ HEAD~1上⼀个版本
◦ HEAD^^上上⼀个版本
◦ 以此类推…
为了便于表述，⽅便测试回退功能，我们先做⼀些准备⼯作：更新3个版本的ReadMe，并分别进⾏3次提交，如下所⽰

第⼀次修改提交
~/gitcode$ cat ReadMe
hello bit
hello git
hello world
hello version1
~/gitcode$ git add ReadMe
~/gitcode$ git commit -m"add version1"
[master cff9d1e] add version1
1 file changed, 1 insertion(+)
# 第⼆次修改提交
~/gitcode$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
~/gitcode$ git add ReadMe
~/gitcode$ git commit -m"add version2"
1 file changed, 1 insertion(+)
# 第三次修改提交
~/gitcode$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
~/gitcode$ git add ReadMe
~/gitcode$ git commit -m"add version3"
[master d95c13f] add version3
1 file changed, 1 insertion(+)
# 查看历史提交记录
~/gitcode$ git log --pretty=oneline
d95c13ffc878a55a25a3d04e22abfc7d2e3e1383 (HEAD -> master) add version3
14c12c32464d6ead7159f5c24e786ce450c899dd add version2
cff9d1e019333318156f8c7d356a78c9e49a6e7b add version1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

现在，如果我们在提交完version3后，发现version3编写错误，想回退到version2，重新基于 version2开始编写。由于我们在这⾥希望的是将⼯作区的内容也回退到 version 2 版本，所以需要⽤到 --hard 参数，⽰例如下

~/gitcode$ git log --pretty=oneline
d95c13ffc878a55a25a3d04e22abfc7d2e3e1383 (HEAD -> master) add version3
14c12c32464d6ead7159f5c24e786ce450c899dd add version2
cff9d1e019333318156f8c7d356a78c9e49a6e7b add version1
...
~/gitcode$ git reset --hard 14c12c32464d6ead7159f5c24e786ce4
HEAD is now at 14c12c3 add version2
~/gitcode$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
1
2
3
4
5
6
7
8
9
10
11
12
13

我们惊奇的发现，此时 ReadMe ⽂件的内容，已经回退到version2了！，当前，我们再次⽤ git log 查看⼀下提交⽇志，发现 HEAD 指向了version2，如下所⽰

~/gitcode$ git log --pretty=oneline
14c12c32464d6ead7159f5c24e786ce450c899dd (HEAD -> master) add version2
cff9d1e019333318156f8c7d356a78c9e49a6e7b add version1
1
2
3

到这⾥⼀般回退功能就演⽰完了，但现在如果我后悔了，想再回到version3怎么办？我们可以继续使⽤ git reset 命令，回退到 version 3 版本，但我们必须要拿到 version 3 的 commitid 去指定回退的版本。
但我们看到了 git log 并不能打印出 version 3 的 commit id ，运⽓好的话我们可以从终端上去找找之前的记录，运⽓不好的话 commit id 已经被我们搞丢了
Git还提供了⼀个 git reflog 命令能补救⼀下，该命令⽤来记录本地的每⼀次命令

~/gitcode$ git reflog
14c12c3 (HEAD -> master) HEAD@{0}: reset: moving to 14c12c32464d6ead7159f5c24e78
d95c13f HEAD@{1}: commit: add version3
14c12c3 (HEAD -> master) HEAD@{2}: commit: add version2
cff9d1e HEAD@{3}: commit: add version1
94da695 HEAD@{4}: commit: add modify ReadMe file
23807c5 HEAD@{5}: commit: add 3 files
c614289 HEAD@{6}: commit (initial): commit my first file
1
2
3
4
5
6
7
8

这样，你就可以很⽅便的找到你的所有操作记录了，但 d95c13f 这个是啥东西？这个是 version3 的 commit id 的部分。没错，Git版本回退的时候，也可以使⽤部分 commit id 来代表⽬标版本 ⽰例如下：

# 回退到v3
~/gitcode$ git reset --hard d95c13f
HEAD is now at d95c13f add version3
# 查看⼯作区
~/gitcode$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
# 查看log
~/gitcode$ git log --pretty=oneline
d95c13ffc878a55a25a3d04e22abfc7d2e3e1383 (HEAD -> master) add version3
14c12c32464d6ead7159f5c24e786ce450c899dd add version2
cff9d1e019333318156f8c7d356a78c9e49a6e7b add version1
94da6950d27e623c0368b22f1ffc4bff761b5b00 add modify ReadMe file
23807c536969cd886c4fb624b997ca575756eed6 add 3 files
c61428926f3853d4ec6dde904415b0e6c1dabcc6 commit my first file
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

可往往是理想很丰满，现实很⻣感。在实际开发中，由于⻓时间的开发了，导致 commit id 早就找不到了，可突然某⼀天，我⼜想回退到version3，那该如何操作呢？貌似现在不可能了
值得说的是，Git的版本回退速度⾮常快，因为Git在内部有个指向当前分⽀（此处是master）的HEAD指针， refs/heads/master ⽂件⾥保存当前 master 分⽀的最新 commit id 当我们在回退版本的时候，Git仅仅是给 refs/heads/master 中存储⼀个特定的version，可以简单理解成如下⽰意图：