Git命令行操作本地库

Git命令行操作

本地库操作
1. 本地库初始化
  1. 命令：git add
  2. 在工作目录下右键鼠标打开 Git Bash Hear
    
    然后执行git init 命令进行初始化
  3. 效果
  4. 会生成一个.get 的隐藏文件目录，如果要看到它，需要通ls -lA 命令来查看
  5. 注意
  6. git目录中存放的是本地库相关的子目录和文件，不要删除，也不要随意修改
2. 设置签名
  1. Git规定开发人员必须设置签名，类似于用户名

2 形式：

用户名：zhangsan

Email地址： [email protected] 可以不存在

3 作用

区分不同的开发人员身份

4 辨析

之前提过的登录代码托管中心的用户名和密码和签名的用户名没有任何关系。

5命令

这里又分为两个级别

1项目级别/仓库级别

仅在当前本地库范围内有效

git config user.name tom_pro

git config user.email [email protected]

在 .git/config文件中查看签名

cat .git/config

2系统用户级别

登陆当前操作系统的用户范围

git -global user.name tom_glob

git -global user.email [email protected]

查看签名

返回系统根目录 cd ~

查看隐藏文件 ls -lA|less

查看内容 cat .gitconfig

如果两个级别同时存在会优先使用项目级别，如果只有系统级别，那么只使用系统用户级别为准，二者都没有则报错！

3添加提交以及查看状态操作
查看工作区和缓存区状态 git status

On branch master 在master 分支

No commits yet 没有任何以及提交的东西，也就是说本地库什么东西都没有

Nothing to commit (Create/copy files and use “git add” to track) 暂存区没有提交的东西

然后按它的提示进行创建文件

然后再执行 git status

会出现以下几行提示：

On branch master 在master 分支
No commits yet 没有任何以及提交的东西，也就是说本地库什么东西都没有
Untrack files
（use “git add <file>...” to include in what will be committed）
good.txt
这里的意思是可以使用 git add good.txt 将这个文件提交到缓存区

然后按照提示进行操作后会出现提示警告
WARN: LF will be replace by CRLF in good.txt
这里的意思是 LF 将被替换成CRLF 即将window的结尾替换成Unix 的结尾
然后再执行 git status 会发现在缓存区出现绿色的good.txt 文件

如果此时要删除缓存区的文件可以使用 git rm --cacahed good.txt

此时再执行git status 后会发现又回到了之前的提示。
重新提交到缓存区然后将缓存区的文件提交到本地库执行 git commit good.txt

4 基本操作总结

状态查看操作（工作区缓存区）

git status

工作区添加文件到缓存区

git add [file name]

缓存区提交到本地库

git commit -m “xxxx” [file name]

查看历史记录操作

git log

git log --pretty= oneline

git log --oneline

git reflog 查看版本移动步数

5 版本后退前进（三种方式）

基于索引值（推荐）

命令

git reset --heard [版本号]

使用异或符号 ^

只能往后退

退一步： git reset --hard HEAD^

退N步： git reset --hard HEAD^^^^^^^ N 个异或符号

使用波浪号~符号

后退三步： git reset --hard HEAD~3

reset 命令的三个参数对比

在命令行使用git help reset命令查看文档

Working Tree 当前的工作区域
Index/Stage 暂存区域，和git stash命令暂存的地方不一样。使用git add xx，就可以将xx添加近Stage里面
Repository 提交的历史，即使用git commit提交后的结果

刚开始 working tree 、 index 与 repository(HEAD)里面的内容都是一致的

当git管理的文件夹里面的内容出现改变后，此时 working tree 的内容就会跟 index 及 repository(HEAD)的不一致，而Git知道是哪些文件(Tracked File)被改动过，直接将文件状态设置为 modified (Unstaged files)。

当我们执行 git add 后，会将这些改变的文件内容加入 index 中 (Staged files)，所以此时working tree跟index的内容是一致的，但他们与repository(HEAD)内容不一致。

接着执行 git commit 后，将Git索引中所有改变的文件内容提交至 Repository 中，建立出新的 commit 节点(HEAD)后， working tree 、 index 与与repository(HEAD)区域的内容又会保持一致。

实验：提交四次

git reset --hard HEAD^

--hard:在本地库移动head指针

重置暂存区

重置工作区

git rest --soft 版本号

保留工作目录，并把重置 HEAD 所带来的新的差异放进暂存区

由于 HEAD 从 4 移动到了 3，而且在 reset 的过程中工作目录和暂存区的内容没有被清理掉，所以 4 中的改动在 reset 后就也成了工作目录新增的「工作目录和 HEAD 的差异」。这就是上面一段中所说的「重置 HEAD 所带来的差异」。

此模式下会保留 working tree工作目录的内容，不会改变到目前所有的git管理的文件夹的内容；也会
保留 index暂存区的内容，让 index 暂存区与 working tree 工作目录的内容是一致的。就只有 repository 中的内容的更变需要与 reset 目标节点一致，因此原始节点与reset节点之间的差异变更集合会存在与index暂存区中(Staged files)，所以我们可以直接执行 git commit 将 index暂存区中的内容提交至 repository 中。当我们想合并「当前节点」与「reset目标节点」之间不具太大意义的 commit 记录(可能是阶段性地频繁提交)时，可以考虑使用 Soft Reset 来让 commit 演进线图较为清晰点。

此时再提交

这就是--soft 和 --hard 的区别：

--hard 会清空工作目录和暂存区的改动,而 --soft则会保留工作目录的内容，并把因为保留工作目录内容所带来的新的文件差异放进暂存区。

reset 不加参数(mixed)：保留工作目录，并清空暂存区

修改文件并放入缓存区，简而言之，就是「把所有差异都混合（mixed）放在工作目录中」。

reset 的本质：移动 HEAD 以及它所指向的 branch

实质上，reset 这个指令虽然可以用来撤销 commit ，但它的实质行为并不是撤销，而是移动 HEAD ，并且「捎带」上 HEAD 所指向的 branch（如果有的话）。也就是说，reset 这个指令的行为其实和它的字面意思 "reset"（重置）十分相符：它是用来重置 HEAD 以及它所指向的 branch 的位置的。

而 reset --hard HEAD^ 之所以起到了撤销 commit 的效果，是因为它把 HEAD 和它所指向的 branch 一起移动到了当前 commit 的父 commit 上，从而起到了「撤销」的效果：

所以同理，reset --hard 不仅可以撤销提交，还可以用来把 HEAD 和 branch 移动到其他的任何地方。

git reset --hard branch2

git 永久删除文件找回

由于已经将文件提交到了本地库，所以本地库会一直存在提交记录，那么想要恢复就很简单，也就是恢复上一个版本而已，相当于把HEAD 指针向下移动一次即可。

git 添加到暂存区删除文件找回

先将文件提交到缓存区然后提交到本地库，然后删除工作区文件，提交到缓存区，但是没有提交到本地库，然后找回

然后通过 git reset --hard HEAD 找回

文件比较 git diff [文件名]

Git命令行操作本地库