前言
曾经听到过这样一句话: 不会 Git 就不要敲代码了. 细细品味确实有其中的道理, 可能是当事人代码被强行覆盖后的叹息吧!
因此, 为了避免这种情况, 接下来我们就一起来好好学习 Git 的相关知识吧! 不怕你不会, 就怕你不看!
一, Git 的三个分区:
工作区(working directory)
暂存区(stage)
版本库
它们之间的关系为:
通过 Git status 查看 Git 状态时, 红色的文件表示在工作区; 绿色的文件表示在暂存区:
工作区中的文件只要通过 Git add 命令添加进了 Git 仓库, 就会被追踪.
二, Git 常用命令
创建版本库 | 版本控制 | 远程协作 | 查看信息 |
---|---|---|---|
git init | git add | git pull | git help |
git clone | git commit | git push | git log |
* | git rm | * | git diff |
三, Git 配置
1.Git config
可以通过三个地方的三个文件设置 Git 配置参数, 分别代表三个不同的作用域:
/etc/gitconfig: 作用域: 一台计算机 (操作系统) 上的所有用户, 几乎不会使用, 优先度低于 --global; 设置方法:
Git config --system
~/.gitconfig: 作用域: 计算机中的某用户创建的所有项目, 常用, 优先度低于 --local; 设置方法:
Git config --global
.Git/config : 作用域: 某一特定的版本库, 不常用, 是最具体的, 优先度最高; 设置方法:
Git config --local
可使用 Git config 查看相关操作命令以及提示:
2.user.name 与 user.email
添加配置
user.name 和 user.email 指的是用户名和邮箱, 这些两个配置会被添加到提交信息中, 可以搭配上述命令配置到三种作用域中:
仓库配置: 通过 --local 命令配置, 作用域为当前版本库, 配置写入. Git/config 文件中, 优先度第一;
- Git config --local user.name "张三"
- Git config --local user.email test1@Git.com
以上为配置特定版本库 (mygit) 的用户和邮箱: 这样配置就可以通过两个版本库来进行多人操作的模拟;
用户配置: 通过 --global 命令配置, 作用域为当前系统用户, 配置写入~/.gitconfig 文件, 优先度第二;
- Git config --global user.name "张三哥哥"
- Git config --global user.email test2@Git.com
系统配置: 通过 --system 命令配置, 作用域为当前操作系统所有用户, 配置写入 / etc/gitconfig 文件, 优先度第三; 这里需要管理员身份运行 Git bash 才有修改权限:
- Git config --system user.name "张三爸爸"
- Git config --system user.email test3@Git.com
查看配置
直接查看配置文件(可通过 cat 指令查看):
仓库配置:.Git/config
用户配置:~/,gitconfig
系统配置:/etc/gitconfig
通过 Git config --list: 可以批量查看配置信息:
通过
Git config user.name/email
查看:
可以看到输出的配置信息是仓库配置张三, 验证了仓库配置的优先级最高;
修改配置
删除 config 配置
Git config --unset <参数名>
首先设置错误参数, 随后查看该配置:
删除该配置:
修改 user.name/email 配置
可以通过添加配置的方式对原有配置进行覆盖, 从而达到修改的效果:
通过 --unset 命令删除指定的配置信息:
我们以该方式继续删除用户配置 --global user.name: 张三哥哥, 和仓库配置 --local user.email:test1@Git.com:
此时再次通过 Git config user.name/email 查看配置信息 user.name/email:
可以发现 user.name 显示的是系统配置: 张三爸爸, user.email 显示的是用户配置: test2@Git.com, 验证了用户配置优先级第二和系统配置优先级第三;
3..gitignore
我们可以通过 Git 提供的. gitignore 文件配置不被 Git 跟踪的文件. 被添加到. gitignore 文件中的文件名, 将不会被 Git 追踪. 如下图中的新增文件 setting.properties:
可见在. gitignore(注意文件是官方规定好了的不能随便乱改)文件中添加了文件名 setting.properties 后, Git 便不再追踪 setting.properties 这个文件了;
应用场景: 通常将不需要提交的项目依赖文件 (如 modules 目录下文件) 添加到. gitignore 文件中, 这样每次提交都会自动忽略这些文件;
只要与. gitignore 中内容相匹配的目录或文件就会被 Git 忽略; 再例:
.gtiignore 文件非常重要, 一般放在创建项目的根目录上.
注意在. gitignore 文件中一行写一个文件名;.gitignore 文件也支持正则表达式比如:
*.a: 忽略所有以 .a 结尾的文件;
!lib.a: 表示除了 lib.a 文件, 其余都会被忽略;
/TODO: 仅仅忽略项目根目录下的 TODO 文件, 不包括 subdir/TODO(TODO 为示例文件);
可以通过 /*/TODO 使一层目录下的 TODO 文件被忽略;
通过 /**/TODO 使所有层目录下的 TODO 文件都被忽略;
build/ 表示忽略 build 目录下的所有文件;
doc/*.txt 表示忽略 doc 目录下所有的. txt 文件, 包括 doc/notes.txt 但不包括
doc/server/.arch.txt
;
doc/*/*.txt 会忽略 doc 目录及其任何一个子目录下的所有. txt 文件, 比如 doc/bin/2.txt(/* 表示一层目录);
而 doc/**/*.txt 则会把 doc 任何一层目录及其子目录下的. txt 文件忽略; 即 /**/ 两颗星表示所有层目录;
以下为某个使用 vue-cli3 创建项目下的. gitignore 文件内容:
- .DS_Store
- node_modules
- /dist
- # local env files
- .env.local
- .env.*.local
- # Log files
- NPM-debug.log*
- yarn-debug.log*
- yarn-error.log*
- # Editor directories and files
- .idea
- .vscode
- *.suo
- *.ntvs*
- *.njsproj
- *.sln
- *.sw?
四, 查看状态
1.Git status
查看工作区的状态, 该命令经常使用; 每执行一条指令后, 都应使用该命令查看工作区和暂存区的状态; 红色表示对文件的更改还没提交到暂存区; 绿色表示已提交到暂存区;
五, 工作区 ->暂存区
1.Git add <file>
将工作区中的文件提交到暂存区:
Git add test.txt: 将工作区中的 test.txt 提交到暂存区;
Git add test.txt test2.txt
: 将工作区中的 test.txt 和 test2.txt 提交到暂存区;
Git add .: 将当前目录及其子目录下的所有文件从工作区提交到暂存区中;
六, 暂存区 ->版本库
- 1.
- Git commit -m '注释'
将暂存区中的文件提交到版本库, 一定要添加注释, 否则不让提交: 当注释很短时采用 - m 方式(m 为 message 的意思):
2.Git commit
当注释很长时, 可以直接执行 Git commit, 进入 VIM 编辑器界面, 在此处编写较长的注释, 添加完注释后, 通过 wq 保存并退出即可:
- 3.
- Git commit -am '注释'
表示添加当前目录下所有已被 Git 追踪的文件到暂存区中并提交, 即相当于是 Git add . 与 Git commit 两步操作的合成.
该方式只适用于已被 Git 追踪的文件 (即文件至少提交过一次), 当文件第一次提交到暂存区时(此时该文件并未被 Git 追踪) 不可以使用该命令, 而是要分开写, 否则会报错:
七, 工作区<- 暂存区
简单来说, 就是将 Git status 指令显示出来的文件, 从绿色变为红色, 大概有如下三种方法:
- 1.
- Git rm --cached <file>
删除缓存区中的 < file > 文件, 并将其还原到工作区. 该指令需要对暂存区删除的文件进行一次提交操作, 所以建议用第二种方法;
- 2.
- Git restore --stage <file>
通过该指令, 将文件从缓存区中移动到工作区, 这里的参数 --stage 写成 --staged 效果是一样的:
小贴士: 可以使用 tab 键补全命令;
- 3.
- Git reset HEAD <file>
将文件从缓存区中移到工作区, 作用与方法 2 一样:
八, 撤销操作
这里指的是撤销工作区中对文件的操作, 包括新增, 修改, 删除等, 配合着前面第七点所讲的指令使用. 大概有以下两种方法:
- 1.
- Git checkout -- <file>
可以撤销工作区中对 flie 文件的改动操作(包括删除): 注意 -- 后面要跟上空格: 如果修改已经通过 Git add 提交到暂存区, 该指令无效.
2.Git restore <file>
可以撤销工作区中对 file 文件的操作, 效果与方法 1 相同;
九, 日志
Git 的日志记录了 Git 仓库对文件的所有操作, 主要分为三大类: 分支的提交日志, 文件的修改日志, Git 的操作日志. 通过查看这些日志信息, 可以很好地了解 Git 仓库的历史记录, 并根据需要进行版本回退.
1. 查看提交日志
使用的主要命令为 Git log, 通过添加不同的参数, 可以显示不同形式的提交日志, 下面主要介绍其中常用的几种:
Git log
查看版本库的提交 (commit) 历史:
提交历史是倒叙的, 最新的提交排在最前面;
Git 的提交 id(commit id)是一个摘要值, 这个摘要值实际上是通过 sha1 算法计算出来的不重复字符串. 由此保证了每次提交 id 的唯一性;
Author 显示的是提交时优先级最高的配置, 比如提交时有 --local 配置就显示它, 没有就显示 --global 的配置; 如上图中: 第二次提交时使用的是修改过后的 config 李四, 也就是优先级更高的 --local 配置;
Git log -n
可以查看最近的 n 次的提交历史, 比如通过 Git log -3 查看最近 3 次的提交历史:
Git log --graph
以图形化的形式显示提交历史:
Git log --pretty=oneline
以一行的形式显示提交历史:
Git log --graph --abbrev-commit
通过 --abbrev-commit 对提交信息进行简化:
还可以结合 --pretty=oneline 进行简写:
Git log --pretty=oneline --abbrev-commit
Git log --pretty=oneline:"%h - %an, %ar : %s"
还可以按照规定的格式显示日志内容:%h: 表示 commit id;%an: 表示提交人;%ar: 表示提交时间;%s: 表示提交信息;
2. 查看修改日志
Git blame file_name
如图所示, 通过该命令可以清楚查看指定的文件的每次修改. 包括修改用户, 修改时间等;
3. 查看操作日志
Git reflog
通过该指令可以详细地查看, 每次操作所在提交节点的 commit id, 以及在此提交节点上所执行的操作(指令); 并且是倒叙显示的, 即最近一次操作的序号为{0}:
Git log: 只能显示当前分支的提交历史, 如果进行版本回退, 会丢失较后版本的提交信息, 如下图所示:
可以看到通过 reset 进行版本回退, 丢失了 4th commit 的提交信息, 此时可通过 Git reflog 查看操作日志的相关操作信息来回到最新的版本.
总结:
总体上来说, 操作日志包含了修改日志和提交日志, 是最全的 Git 日志;
注意: 不是通过 Git 命令, 而是手动修改文件, 这些修改记录不会被 Git 日志记录. 所以, 推荐使用 Git 指令进行操作;
来源: https://www.cnblogs.com/AhuntSun-blog/p/12679145.html