git的一些常用命令及规范(一）

雨～旋律

已于 2022-04-20 00:05:53 修改

阅读量540

点赞数 1

文章标签： git java

于 2022-04-19 23:37:11 首次发布

本文链接：https://blog.csdn.net/qq_44754515/article/details/124259647

版权

一、前言

本文主要是对公司技术培训中提及的一些git培训和git命令做一些记录，并不会进行全范围的笔记记录。

二、angular代码规范

我们公司提交代码遵循该规范，那么下面就来对该规范进行一定的了解：
Commit message 是开发的日常操作，它可以提供更多的历史信息，方便向团队清晰准确地说明代码变更、进行代码评审，也便于后期快速定位原始需求或缺陷，还可以有效的生成 Change log，对项目的管理实际至关重要，但是实际工作中却常常被大家忽略：
Commit Message 格式
目前，社区有多种 Commit message 的写法规范，但使用较多的是 Angular 团队的规范，继而衍生了 Conventional Commits specification常规提交规范。同时，很多配套工具也是基于此规范。

每个 commit message 均由 header，body 和 footer 组成。header 具有一种特殊的格式，其中包括 type，scope 和 subject。
它的 message 格式如下:

<type>(<scope>): <subject>
// 空白行
<body>
// 空白行
<footer>

Commit message 的任何一行都不能超过 100 个字符，这使得该消息在 GitHub 以及各种 git 工具中更易于阅读。

①Header

header 是必填的，描述主要修改类型和内容，header 的 scope 是可选的。

Type

必须为以下之一：

feat：一项新功能
fix：一个错误修复
docs：仅文档更改
style：不会影响代码含义的更改（空格，格式，缺少分号等）
refactor：既不修正错误也不增加功能的代码更改
perf：代码更改可提高性能
test：添加缺失的测试或更正现有的测试
build：影响构建系统，CI 配置或外部依赖项的更改（比如：gulp，npm）
chore：其他不会修改 src 或测试文件的更改（比如文档修改，构建流程）
release：发布版本提交

Scope

可选的，可以是指定提交更改位置的任何内容，例如菜单，侧边栏等。

Subject

subject 包含对变更的简洁描述：
使用第一人称现在时的命令性语气开头，如 change，而不是 changed 或 changes
第一个字母不要大写
末尾不加句号（。）
例如：

git commit -m "fix(core): 修复了内核的一个xx bug"

②Body

可选行，主要用于介绍本次更改背后的动机或仅描述一些更详细的信息

③Footer

可选行，可以备注由于更改而产生的影响，例如：宣布重大更改、链接关闭已解决的问题(issues)、提及贡献者等等
完全的提交示例：

git commit -m "fix(core): 修复了内核的一个xx bug" -m "此次修复了之前一直导致系统不稳定的问题" -m "关闭issue xx"

三个-m后面分别代表三个部分

三、常用git命令

深入理解git命令，必须理解git仓库相关的几个概念。先看一下一份本地代码目录D:\gittest目录下：
在这里插入图片描述
需要注意的是.git是隐藏目录，需要显示隐藏文件才能看到。
工作区（working directory）：简单来说保存在本地的文件或目录都属于工作区，平常修改代码都是在工作区进行的。一般本地的文件，除了隐藏的.git目录，其它都属于工作区。上图中看到的mydir、file1.txt、file2.txt都是属于工作区。
暂存区（Stage）：又称索引区（index），顾名思义，它是工作区与本地仓库之间的一个过渡，它记录了工作区的代码状态（有无改动，或者作了哪些改动）。位于.git目录中。
本地仓库（repository）:记录了本地代码的状态，位于.git目录中。

3.1 设置用户签名

1）基本语法

git config --global user.name 用户名
git config --global user.email 邮箱

说明：
签名的作用是区分不同操作者身份。用户的签名信息在每一个版本的提交信息中能够看到，以此确认本次提交是谁做的。 Git首次安装必须设置一下用户签名，否则无法提交代码。
※注意：
这里设置用户签名和将来登录 GitHub（或其他代码托管中心）的账号没有任
何关系。

3.2 初始化本地库

基本语法

git init

git init 命令用于在目录中创建新的 Git 仓库。
在目录中执行 git init 就可以创建一个 Git 仓库了。
2）案例实操
在这里插入图片描述
现在你可以看到在你的项目中生成了 .git 这个子目录，这就是你的 Git 仓库了，所有有关你的此项目的快照数据都存放在这里。

3）结果查看
在这里插入图片描述

3.3 查看本地库状态

1 基本语法

git status

用于查看在你上次提交之后是否有对文件进行再次修改。
2）案例实操
首次查看（工作区没有任何文件）
在这里插入图片描述
新增文件 hello.txt

再次查看（检测到未追踪的文件）

通常我们使用 -s 参数来获得简短的输出结果：
比方我们如果只通过git status:

然后通过-s查看：

AM 状态的意思是这个文件在我们将它添加到缓存区之后又有改动。

3.4 添加暂存区

3.4.1 将工作区的文件添加到暂存区

1）基本语法
git add 命令可将该文件添加到暂存区。
添加一个或多个文件到暂存区：

git add [file1] [file2] ...

git add [dir]

添加当前目录下的所有文件到暂存区：

git add .

2）案例实操
以下实例我们添加两个文件：
在这里插入图片描述
git status 命令用于查看项目的当前状态。
接下来我们执行 git add 命令来添加文件：

现在我们再执行 git status，就可以看到这两个文件已经加上去了。

新项目中，添加所有文件很普遍，我们可以使用 git add . 命令来添加当前项目的所有文件。
现在我们修改 README 文件：
在 README 添加以下内容：# Runoob Git 测试，然后保存退出。
再执行一下 git status：
在这里插入图片描述
AM 状态的意思是这个文件在我们将它添加到缓存之后又有改动。改动后我们再执行 git add . 命令将其添加到缓存中：

文件修改后，我们一般都需要进行 git add 操作，从而保存历史版本。

3.5 提交本地库

1）基本语法
git commit 命令将暂存区内容添加到本地仓库中。
提交暂存区到本地仓库中:

git commit -m [message]

[message] 可以是一些备注信息。
提交暂存区的指定文件到仓库区：

$ git commit [file1] [file2] ... -m [message]

关于提交规范这里就不做赘述
-a 参数设置修改文件后不需要执行 git add 命令，直接来提交

$ git commit -a

2）案例实操
接下来我们就可以对 hello.php 的所有改动从暂存区内容添加到本地仓库中。
以下实例，我们使用 -m 选项以在命令行中提供提交注释。
在这里插入图片描述
现在我们已经记录了快照。如果我们再执行 git status:

以上输出说明我们在最近一次提交之后，没有做任何改动，是一个 “working directory clean”，翻译过来就是干净的工作目录。

如果你没有设置 -m 选项，Git 会尝试为你打开一个编辑器以填写提交信息。如果 Git 在你对它的配置中找不到相关信息，默认会打开 vim。屏幕会像这样：
在这里插入图片描述
如果你觉得 git add 提交缓存的流程太过繁琐，Git 也允许你用 -a 选项跳过这一步。命令格式如下：

git commit -a

我们先修改 hello.php 文件为以下内容：
在这里插入图片描述
再执行以下命令：

3.7 查看历史版本

1）基本语法

git reflog 查看版本信息
git log 查看版本详细信息

2）案例实操
在这里插入图片描述
说明：
0）.最左侧黄色字体列为修改的commit的前7位，根据7位可以将代码恢复到对应节点位置。

（1）.{n}表示HEAD更改历史记录，最近的操作在上面。
（2）.通过HEAD{n}语法可以引用存在reflog中的提交。
（3）.与HEAD~n功能类似，但HEAD{n}引用的是reflog记录中的commit提交，而HEAD~n引用是commit提交历史记录。
（4）.rebase commit等为git操作与提交节点相关的具体指令。
（5）.最后一个冒号后面的字串为提交信息的摘要信息。

3.8 版本穿梭

1）基本语法
git reset 命令用于回退版本，可以指定退回某一次提交的版本。
git reset 命令语法格式如下：

git reset [--soft | --mixed | --hard] [HEAD]

–mixed 为默认，可以不用带该参数，用于重置暂存区的文件与上一次的提交(commit)保持一致，工作区文件内容保持不变。再次提交时需要 git add

git reset  [HEAD]

案例

$ git reset HEAD^            # 回退所有内容到上一个版本  
$ git reset HEAD^ hello.php  # 回退 hello.php 文件的版本到上一个版本  
$ git  reset  052e           # 回退到指定版本

–soft 参数用于回退到某个版本,回退时保留源码，仅仅回退 commit，修改的文件仍然保存在暂存区,再次提交时只需要 git commit

git reset --soft HEAD

例如：

$ git reset --soft HEAD~3 # 回退上上上一个版本

–hard 参数撤销工作区中所有未提交的修改内容，将暂存区与工作区都回到上一次版本，并删除之前的所有信息提交：

git reset --hard HEAD

实例：

$ git reset –hard HEAD~3  # 回退上上上一个版本  
$ git reset –hard bae128  # 回退到某个版本回退点之前的所有信息。 
$ git reset --hard origin/master    # 将本地的状态回退到和远程的一样

注意：谨慎使用 –hard 参数，它会删除回退点之前的所有信息。
HEAD 说明：

HEAD 表示当前版本
HEAD^ 上一个版本
HEAD^^ 上上一个版本
HEAD^^^ 上上上一个版本
以此类推…

可以使用～数字表示

HEAD~0 表示当前版本
HEAD~1 上一个版本
HEAD^2 上上一个版本
HEAD^3 上上上一个版本
以此类推…

2）案例实操
我们刚才已经知道git reset HEAD 命令用于取消已缓存的内容。
我们先改动文件 README 文件，内容如下：
在这里插入图片描述
hello.php 文件修改为：

现在两个文件修改后，都提交到了缓存区，我们现在要取消其中一个的缓存，操作如下：

现在你执行 git commit，只会将 README 文件的改动提交，而 hello.php 是没有的。

可以看到 hello.php 文件的修改并未提交。
这时我们可以使用以下命令将 hello.php 的修改提交：’
在这里插入图片描述
简而言之，执行 git reset HEAD 以取消之前 git add 添加，但不希望包含在下一提交快照中的缓存。
ps:git reset我们将会在下一章与git checkout,git reset去进行对比！