菜鸟感觉自己还是有点畏难心里，不敢去打链表代码，所以先来写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 <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: gitone.txt Untracked files: (use "git add <file>..." 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 <file>..." 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 <file>..." to update what will be committed) (use "git restore <file>..." 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 <file>..." to update what will be committed) (use "git restore <file>..." 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