git学习 工作区和暂存区 / 管理修改（第三天）
菜鸟感觉自己还是有点畏难心里，不敢去打链表代码，所以先来写git了，不过菜鸟逃不掉的，逼死自己也必须写，不然怎么变强
写一半，菜鸟突然想起来，第一天的linux好像还没搞，ggswl，找时间试试，然后看看是不是要补充（, ,ԾㅂԾ, ,）
文章目录
- 工作区和暂存区
-
- 工作区（Working Directory）：
- 版本库（Repository）
-
- 注意：
- 接下来回到正题！
- 菜鸟时间
- 管理修改
工作区和暂存区
Git和其他版本控制系统如SVN的一个不同之处就是有暂存区的概念。
工作区（Working Directory）：
工作区就是你在电脑里能看到的目录，比如菜鸟的Git_warehouse文件夹就是一个工作区：
版本库（Repository）
工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。
Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。（分支stage和HEAD的概念我们以后再讲，这个HEAD指针在上一节也提到了，就在版本回退那里）
前面讲了我们把文件往Git版本库里添加的时候，是分两步执行的：
- 第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区
- 第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支
因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，git commit就是往master分支上提交更改。
你可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。（这里就是为什么可以add多个文件后，一次性commit）
还是实践出真理，大家可以修改一下自己的文件，然后再新建一个文本文件到工作区（暂时不用提交到git仓库），然后运行 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: gitone.txt
Untracked files:
(use "git add ..." to include in what will be committed)
gittwo
no changes added to commit (use "git add" and/or "git commit -a")
注意：
菜鸟发现git似乎默认就是linux的操作系统，你可以直接在 git bash 上使用 vim < filename > 创建文本文件，在windows上也会展示出来，只是没有.txt后缀 ！而且很多Linux命令都可以使用，读者自行尝试！
这是windows命令行：
这是git bash：
接下来回到正题！
Git非常清楚地告诉我们，gitone.txt被修改了(Changes not staged)，而gittwo还从来没有被添加过，所以它的状态是Untracked。
现在，使用两次命令 git add ，把gitone.txt和gittwo都添加后，用 git status 再查看一下：
On branch master
Changes to be committed:
(use "git restore --staged ..." to unstage)
modified: gitone.txt
new file: gittwo
注意：这里如果是在 git bash 中用 vim 创建的文件，那么这里会有警告，可以不用管，不过菜鸟还是为大家搜好了，link
现在，暂存区的状态就变成这样了（这是别人的图，所以大家自行屏蔽吧，把readme和LICENSE看成菜鸟的gitone和gittwo）：
所以，git add命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支。
一旦提交后，如果你又没有对工作区做任何修改，那么工作区就是“干净”的：
菜鸟时间
这里菜鸟其实发现了问题，那就是，这时候有两个文件，那git是分开管理？还是一起管理？
于是菜鸟git log了，结果如下：
commit 42de1b7f1832d7211d739a048eebad9f7a644da6 (HEAD -> master)
Author: *****
Date: Fri Jul 3 16:07:57 2020 +0800
try stage
commit d696468860aab706dfb385ea4c85a11a0e37d86f
Author: *****
Date: Wed Jul 1 15:51:10 2020 +0800
read boke to change
commit d0e121c1329a54c6224a45c1a0a4952a9d420e40
Author: *****
Date: Wed Jul 1 15:39:34 2020 +0800
add four line
commit ff8a5d3a208ac8f170ee00806205cc997824ad23
Author: *****
Date: Wed Jul 1 15:09:00 2020 +0800
add three line
commit 5222f9d5ca0ea5ef06bf8b43d74ae1ea066d30c9
Author: *****
Date: Wed Jul 1 15:04:59 2020 +0800
add one line
commit c471641b05472dda4ae61331250062da0844ce5a
Author: *****
Date: Mon Jun 29 19:25:28 2020 +0800
2020 6 29
发现里面并没有显示gittwo的版本信息，所以菜鸟很奇怪，于是菜鸟修改了一下gittwo（还是用vim修改的），然后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: gittwo
no changes added to commit (use "git add" and/or "git commit -a")
这里很明显的可以看出，只要在一个仓库里，那么git就会默认两个是有关联的，所以会一起管理！
管理修改
下面，我们要讨论的就是，为什么Git比其他版本控制系统设计得优秀，因为Git跟踪并管理的是修改，而非文件。
为什么说Git管理的是修改，而不是文件呢？我们还是做实验。第一步，对gittwo做一个修改，比如：加一行内容，然后添加到暂存区，然后再次修改gittwo，最后提交到git仓库。提交后，再用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: gittwo
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也可以，菜鸟尝试修改两个文件，发现再用git diff也是一样的可以显示，这种写法是，表示只想看某一个文件和该文件HEAD版本的区别！)：
warning: LF will be replaced by CRLF in gittwo.
The file will have its original line endings in your working directory
diff --git a/gittwo b/gittwo
index da64460..ab83e4f 100644
--- a/gittwo
+++ b/gittwo
@@ -1,3 +1,3 @@
this is two git!
try change to see status!
-try xiugai!
+try guanlixiugai!
可见，第二次修改确实没有被提交。（读者修改肯定跟我不一样，所以以自己为准）
那怎么提交第二次修改呢？你可以继续git add再git commit，也可以别着急提交第一次修改，先git add第二次修改，再git commit，就相当于把两次修改合并后一块提交了：
第一次修改 -> git add -> 第二次修改 -> git add -> git commit