git的一些常用命令讲解和开发规范总结

一、git基本配置介绍

1. config的三个作用域

• local：区域为本仓库

• global: 当前用户的所有仓库

• system: 本系统的所有用户

2. 添加最小配置

$ git config --global user.name 'yfy'   
$ git config --global user.email 'yfy@163.com'

3. 查看配置

$ git config --local --list  ##只能在仓库里面起作用, 普通路径git不管理
$ git config --global --list
$ git config --system --list

4. 清除设置

$ git config --unset --local user.name
$ git config --unset --global user.name
$ git config --unset --system user.name

二、git命令

1.git log

• git log --all 查看所有分支的历史
• git log --all --graph 查看图形化的 log 地址
• git log --oneline 查看单行的简洁历史。
• git log --oneline -n4 查看最近的四条简洁历史。
• git log --oneline --all -n4 --graph 查看所有分支最近 4 条单行的图形化历史。
• git help --web log 跳转到git log 的帮助文档网页

我们可以设置一个别名，自定义git l查看的样式

alias.l=log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --all

 

2.删除分支

git branch -d 分支名  #在删除前Git会判断在该分支上开发的功能是否被merge到其它分支。如果没有，不能删除。如果merge到其它分支，但之后又在其上做了开发，使用-d还是不能删除
git branch -D 分支名  #会强制删除

3.撤销commit

执行commit后，还没执行push时，想要撤销这次的commit，该怎么办？

git reset --soft HEAD^

如果想要连着add也撤销的话，--soft改为--hard（删除工作空间的改动代码）。

git reset --hard HEAD^
--soft
不删除工作空间的改动代码 ，撤销commit，不撤销git add file
--hard
删除工作空间的改动代码，撤销commit且撤销add

3.修改commit的message

git commit --amend  #对最新一次提交做 commit 修改
git rebase -i father_commit_id  #修改历史的commit，输入它的父亲节点
git rebase -i --root  #若没有父亲节点，则用该命令

4.合并commit

我们使用git log命令查看最近3次的提交，我们想要将最近两次请求合并成一次commit。

 

输入如下命令:

这里面的commitId是你要合并的两个commit后所形成的一个commitId需要跟着的commitId。在这边也就是add log 1的commitId.

git rebase -i commitId

 

进入vi模式后，在键盘上敲i键进入insert模式。这时候先看看这里面的东西是什么含义，

• pick 的意思是要会执行这个 commit

• squash 的意思是这个 commit 会被合并到前一个commit

我们需要将add log3合并到add log2中，修改成如下：

squash也可以按照上面的注释所给出的，直接使用简写 s

 

wq保存后进入一个新页面

 

我们可以重新编辑该commit

 

提交完毕后，git log查看我们提交的日志，发现确实合并了

 

5.比较暂存区和HEAD的差异

vi index.html 修改index.html的内容
git add index.html 将修改的文件添加到暂存区
git status 显示在哪个暂存区 有没有文件改变将要提交
git diff --cached 查看文件改变情况 看变更的文件有没有问题
git commit -m 'Add index.html' 做提交操作

6.比较工作区和暂存区的差异

假定：HEAD、缓存区、工作区中的readme.md文件内容均不相同。
git diff HEAD -- readme.md # 工作区 <===> HEAD
git diff -- readme.md # 工作区 <===> 暂存区
git diff --cached -- readme.md # 暂存区 <===> HEAD

7.暂存区/工作区恢复到和HEAD一样

git reset HEAD
​
git reset 有三个参数
--soft 这个只是把 HEAD 指向的 commit 恢复到你指定的 commit，暂存区 工作区不变
--hard 这个是 把 HEAD， 暂存区， 工作区 都修改为 你指定的 commit 的时候的文件状态
--mixed 这个是不加时候的默认参数，把 HEAD，暂存区 修改为 你指定的 commit 的时候的文件状态，工作区保持不变

8.工作区恢复到暂存区

我们有个文件修改了，然后add到暂存区。然后在工作区继续开发后，发现改的不是那么理想，想回到暂存区，则执行以下命令。

git restore/checkout 文件名
# 上面2个是git不同版本的命令，效果都一样。我们可以用git status查看需要使用什么命令

 

9.查看不同提交的文件差异

git diff <commit_id1> <commit_id2> --<file_name>  #比较某文件两次不同提交的差异
git diff <branch_1> <branch_2> -- <file_name>  #比较某文件两个不同分支的差异

10.删除文件

git rm filename  #删除文件，注意，只是把工作区和暂存区对应的文件删除了，远程仓库的需要push

11.git stash

当开发中临时加塞了紧急任务怎么处理？

有时候我们会将开发中的代码先commit，然后新拉一个分支去改临时需求，改完后合并到主分支中。其它开发更新主分支的代码，然后继续开发。

那么，如果我们只是开发了一半，并不想commit呢，我们可以先将代码存放到暂存区中，当紧急任务开发完毕后，stash pop将代码恢复，继续开发。

此时若紧急任务修改的代码和目前代码冲突了，两次更改都在，手动解决冲突即可。

git stash save "save message" #把当前工作区的内容放入暂存区，只有git stash 也要可以的，但查找时不方便识别。
git stash list #查看stash了哪些存储
git stash pop stash@{$num} #把暂存区的内容恢复到工作区，且删除，默认为第一个stash,即stash@{0}
git stash apply stash@{$num} #把暂存区的内容恢复到工作区，且保留，默认为第一个stash,即stash@{0}
git stash drop stash@{$num} #丢弃stash@{$num}存储，从列表中删除这个存储
git stash clear #删除所有缓存的stash

12.gitignore

我们做的每个Git项目中都需要一个“.gitignore”文件，这个文件的作用就是告诉Git哪些文件不需要添加到版本管理中。

/mtk/ 过滤整个文件夹
*.zip 过滤所有.zip文件
/mtk/do.c 过滤某个具体文件

以上规则意思是：被过滤掉的文件就不会出现在你的GitHub库中了，当然本地库中还有，只是push的时候不会上传。 除了以上规则，它还可以指定要将哪些文件添加到版本管理中。

!src/   不过滤该文件夹
!*.zip   不过滤所有.zip文件
!/mtk/do.c 不过滤该文件

配置语法：

• 以斜杠/开头表示目录；

• 以星号*通配多个字符；

• 以问号?通配单个字符

• 以方括号[]包含单个字符的匹配列表；

• 以叹号!表示不忽略(跟踪)匹配到的文件或目录；

如果提交commit后，想再忽略一些已经提交的文件，我们可以把想忽略的文件添加到 .gitignore，在使用如下命令：

 git rm -- cached name_of_file #删除掉git仓库里面无需跟踪的文件。

三、git开发规范

1.分支命名

master 分支

• master 为主分支，也是用于部署生产环境的分支，确保master分支稳定性

• master 分支一般由develop以及hotfix分支合并，任何时间都不能直接修改代码

develop 分支

• develop 为开发分支，始终保持最新完成以及bug修复后的代码

• 一般开发的新功能时，feature分支都是基于develop分支下创建的

feature 分支

• 开发新功能时，以develop为基础创建feature分支

• 分支命名: feature/ 开头的为特性分支， 命名规则: feature/user_module、 feature/cart_module

release分支

• release 为预上线分支，发布提测阶段，会release分支代码为基准提测

当有一组feature开发完成，首先会合并到develop分支，进入提测时，会创建release分支。 如果测试过程中若存在bug需要修复，则直接由开发者在release分支修复并提交。 当测试完成之后，合并release分支到master和develop分支，此时master为最新代码，用作上线。

hotfix 分支

• 分支命名: hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似

• 线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支，修复完成后，需要合并到master分支和develop分支

2.commit规范

当前业界应用的比较广泛的是 Angular Git Commit Guidelines

格式为：

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

• type: 本次 commit 的类型，诸如 bugfix docs style 等

• scope: 本次 commit 波及的范围

• subject: 简明扼要的阐述下本次 commit 的主旨

• body: 在主体内容中我们需要把本次 commit 详细的描述一下，比如此次变更的动机，如需换行，则使用 |

• footer: 描述下与之关联的 issue 或 break change，详见案例

Type的类别说明：

• feat: 添加新特性

• fix: 修复bug

• docs: 仅仅修改了文档

• style: 仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑

• refactor: 代码重构，没有加新功能或者修复bug

• perf: 增加代码进行性能测试

• test: 增加测试用例

• chore: 改变构建流程、或者增加依赖库、工具等