Git的基本操作
目录
关于Git
在我们的⼯作或学习时，可能会出现下面的情况：
我们在编写各种⽂档时，为了防止⽂档丢失或更改失误，为了能恢复到原来的版本，不得不复制出⼀个副本
但是会出现一个问题：
随着版本数量的不断增多，我们并不记得这些版本各自都是修改了什么
所以为了能够更⽅便我们管理这些不同版本的文件，便有了版本控制器，版本控制器就是⼀个可以记录工程的每⼀次改动和版本迭代的⼀个管理系统，同时也方便多人协同作业
我们目前最主流的版本控制器就是Git了，Git可以控制电脑上所有格式的⽂件，例如doc、excel等等，对于开发人员来说，Git最重要的就是可以帮助我们管理软件开发项目中的源代码文件
但是Git并不是万能的，具体看下面的例子：
算法版本控制系统Git，只能跟踪文本文件的改动，比如TXT文件、程序代码等等，版本控制系统可以告诉你每次的改动，⽐如在第5⾏加了⼀个单词“apple”。而图⽚、视频这些⼆进制⽂件，虽然也能由版本控制系统管理，但也就只知道图⽚从100KB改成了120KB，但到底改了什么，版本控制系统不知道，也没法知道
Git的安装
下面演示在Linux中安装Git，下面演示的是centos平台下的安装：
只需要在Linux中输入sudo yum install git -y即可安装Git
安装完成后输入git --version，可以查看是否安装：
可以看到完成安装，安装的是1.8.3.1的版本
Git基本操作
创建Git本地仓库
仓库是进行版本控制的⼀个文件⽬录。我们要想对文件进行版本控制，就必须先创建一个仓库出来
mkdir创建一个gitcode的目录，进入目录发送什么都没有，因为是刚刚创建的
接下来使用 git init，可以在当前文件目录下创建一个Git本地仓库
就可以看到当前目录下，多了一个.git的隐藏文件，如下tree .git观察.git文件的内容
这里面的内容是Git用于追踪管理仓库的，我们不要手动去更改，不然就会破坏Git仓库
配置本地仓库
接着就需要配置name和email
使用 git config user.name "name" 和 git config user.email "email"
从而配置自己的name和email了
配置完成后，通过 git config -l 查看是否配置成功：
如果想删除配置，执行：
git config --unset user.name
git config --unset user.email
即可删除配置的name和email
因为一台机器上可能会有多个仓库，如果想让配置的name和email在当前机器的所有仓库中都生效，就加上--global选项：
git config --global user.name "name"
git config --global user.email "email"
同样要想删除加 --global 选项后创建的配置name和email，在--unset前面也需要加上--global,即：
git config --global --unset user.name
git config --global --unset user.email
工作区、暂存区、版本库
我们在gitcode的路径下创建一个ReadMe文件：
但是目前，git不能管理ReadMe文件
因为gitcode并不是本地仓库，真正的本地仓库是隐藏的 .git，也叫做版本库
但是我们也不允许在 .git 下手动修改
所以把 gitcode 称之为工作区
版本库中有一个暂存区(stage)，也叫做索引(index)
版本库还有一个head指针，指向master分支
版本库中也有一个对象库(objects)，修改的工作区内容会写入对象库中的一个新的git对象中，所以这里维护了这些对象，也就做到了对版本的管理
第一步：add
将工作区修改(新增、修改、删除)的内容，保存到版本库的暂存区中
第二步：commit
将暂存的内容，提交到master分支下
由于暂存区和master里都是索引，这里的索引都指向了对象库，也就能够得到了文件具体修改的内容，也就可以管控一个文件了
所以关系也就如下图所示：
通过观察 .git 的内容结构，也可以与上面的内容对应上，但是由于我们还没有向暂存区add内容，所以暂时看不到暂存区：
添加文件
首先，我们先在ReadMe中写一行内容：
保存退出后，先执行add命令：
可以 git add ReadMe，也可以 git add .
再执行 git commit -m "提交的细节"：
此时会显示一个文件改变，也就是ReadMe文件提交上去了
此时执行 git log，可以打印出我们的提交记录：
commit后面一长串的内容是commit ID，是经过哈希计算出来的
Author是谁提交的
Date是提交日期
如果执行 git log --pretty=oneline，就能够打印的漂亮可观一些
add 是将文件放入暂存区中，而 commit 是将暂存区的内容写入到本地仓库中的
查看 .git 文件
此时再 tree .git查看结构，就有了index：
在上面也说到过，head指针会指向master，下面查看head的指向：
再观察master中存储的内容：
这里面存储的也就是我们最近一次提交的commit ID
此时观察上面cat出来的.git的内容中的objects：
commit ID的前两位是objects的文件名，也就是fd，后面的是内容
可以使用 git cat-file -p 内容 进行查看：
结果显示是 第一次提交的信息
接着查看倒数第二个 commit ID：
结果显示是前面提交的ReadMe文件
再查看倒数第三个 commit ID：
这里面就是我们第一次提交的内容
下面总结一下：
.git文件中有 index 和 head 指针，head指向了 refs/heads/master，而master中存放的是commit ID，这里的commit ID是一个个对象，被维护在了对象库objects中，对象库中存放的文件就是之前提交的一些内容
修改文件
Git 追踪管理的其实是修改，而不是文件
上面说到了，新增、修改、删除都算对工作区的修改
下面将前面创建的 ReadMe文件 做以修改：
接着使用 git status ：查看上一次提交之后到现在为止，是否对文件进行过修改
可以看到 ReadMe文件 被修改了
但是 git status 只能查看哪个文件被修改了，如果像查看修改了什么内容，就需要使用：
git diff + 文件名
下面解释一下打印出的 diff 格式的内容：
-
--git：表示 diff 是 git格式的
-
a/b：表示 改动前/改动后 的文件名
-
---/+++：同样表示 改动前/改动后
-
-1 +1 2：表示改动前的第一行与改动后的第一行，连续两行的内容，下面的+开头的就是修改的内容
接着 git add ReadMe，提交到暂存区后，再执行 git status 观察状态：
提示我们需要将改变的内容执行 commit
下面 commit 后，再执行 git status 观察：
此时告诉我们：
没有什么可以提交了，工作区是干净的
版本回退
Git 能够管理文件的历史版本，这也是版本控制器重要的能力。如果有一天你发现之前做的工作出现了很大的问题，需要在某个特定的历史版本重新开始，这个时候就需要版本回退的功能了
观察此时的 ReadMe文件，是有2行内容的，但是需 要注意：
我们第一次提交时只有一行内容，第二行是后来添加进去的，所以 ReadMe文件 是有两个版本的
-
版本一：hello git!!
-
版本二：hello git!!
hello world!!
回退的命令：
git reset [--soft] [--mixed] [--hard] [HEAD]
其中的三个选项是有不同作用的，下面是执行不同的选项，三个区域中的内容变化：
-
mixed 是默认选项，不加选项时默认是 mixed
-
hard 慎用，因为hard会将我们工作区没有提交的代码也回退，执行后就找不到工作区代码了
下面首先执行 git log --pretty=online，查看历史日志，可以看到之前是提交了两次的：
我们想回退到第一个版本，使用 git reset --hard + commit ID:
注意：
在这之间提交的文件都会被回退
此时打印 ReadMe文件 的内容，发现确实只剩下 hello git!! 了：
此时再打印日志，就只剩下第一次提交的内容了：
如果后悔了，想回退到之前的版本，那就再执行 git reset --hard，加上之前执行 git log 时打印的commit ID，也就是这一条：
执行 git reset 后，再打印 ReadMe文件，也就回退回来了：
那么如果我们回退后，clear了或是退出云服务器了，无法查看上一次日志中的 commit ID 了，那么就需要使用 git reflog ，来查看之前的 commit ID了：
前面这个比较短的一串字符，就是 commit ID
上述情况是我们能够找到 commit ID的情况，如果出现我们无法找到 commit ID 的情况时，就无法回退成功了
那么版本回退为什么速度这么快能够回退呢
很简单，因为有一个 head指针 指向 master，而 master 中存储的是 commit ID，commit ID就是一个 git 对象，git 对象中有曾经存放的内容
画个草图也就是下面这种样子：
只是改变了 master中的 commit ID，只改变 commit ID 速度是很快的
撤销修改
撤销修改指的就是：写了一段时间代码后，觉得自己写的代码质量不好，想恢复到修改前的上一个版本的代码
情况一：对于工作区的代码，还没有 add，想撤销
例如此时继续给 ReadMe文件 新增一行内容：
最简单的方式就是，我们手动将新增的内容删除即可，但是这种方式在工作中某些情况是不可取的，如果我们写了好几天的代码几百行，我们手动删除第一比较费时间，第二可能会涉及修改老的代码，此时删除会有 bug，所以这种方式排除
git 提供了一种方式，可以将工作区文件回到最近一次 add / commit 的状态：
git checkout -- 文件名
情况二：工作区和暂存区都有这份修改的代码，想撤销
同样在 ReadMe文件 中添加代码：
并提交到暂存区中，执行 git status 观察到 ReadMe文件 是被提交到暂存区中了：
此时想撤销修改，就需要用到上面的版本回退中的 git reset 了
因为此时只修改了工作区和暂存区的内容，版本库可以看做空也就是没有改变，所以使用 git reset 撤销修改，可以看做是回退到版本库的当前版本
因此可以使用 reset 的 --mixed 或是 --hard选项，区别就是：
-
使用 --mixed，只回退了暂存区的代码，工作区的代码我们还需要使用情况一的处理方法处理
-
使用 --hard，工作区和暂存区的代码都回退了，不需要额外处理了
使用 --mixed：
由于 --mixed 是默认版本，所以可以不加选择，回退到当前版本，就执行 git reset HEAD 文件名
回退到前一个版本就是 git reset HEAD^
再执行 git status，得知暂存区没有内容需要被提交，说明暂存区的内容被撤销了：
此时就回到了情况一的场景，执行 git checkout -- ReadMe 即可：
上面显示工作区是干净的，再打印 ReadMe文件，发现新增的内容被撤销了：
情况三：工作区、暂存区、版本库都存在想撤销的代码
此时当版本库中存在修改的内容，当前版本就是修改代码后的版本，而上一版才是不包含修改后的代码
回退这种情况的前提条件是：add、commit之后，没有进行 push操作(提交到远程仓库中)
撤销的目的，就是不影响远程仓库的代码
下面同样对 ReadMe文件 新增一行代码，也就是修改工作区的代码：
接着 add、commit 修改 暂存区和版本库 的代码：
下面使用 git reset --hard HEAD^，回退到上一个版本
注意是回退到上一个版本，因为版本库也修改了，所以事项回退到版本库的上一个版本
接着再执行 git status 和 打印 ReadMe文件，观察是否回退成功，显示都成功了
删除文件
删除版本库中的文件
首先我们先多创建几个文件提交到版本库中，此时有三个文件：
方式一：三步删除文件
先将工作区的 file2 删除：
再将暂存区的 file2 删除：
再将版本库中的 file2 删除
方式二：三步删除文件
执行使用 git rm 文件名，同时删除 工作区和暂存区 的 file1文件
删除版本库的文件：
至此就删除成功了
git的基本操作到此结束
原文地址：https://blog.csdn.net/m0_64411530/article/details/138200068
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！