git的入门使用和规范

在github新建一个仓库

此命令初始化一个新本地仓库

git init

目文件夹下面的文件都添加进来

git add .

提交说明

git commit -m '信息备注'

让本地仓库和远程仓库建立连接

git remote add origin + //远程仓库地址

拉取最新仓库

git pull

把本地仓库push到github上面

git push origin master
$ git push origin master --再提交本地就好了

显示所有远程仓库

git remote -v

一、为什么需要规范？

无规矩不成方圆，编程也一样。
如果你有一个项目，从始至终都是自己写，那么你想怎么写都可以，没有人可以干预你。可是如果在团队协作中，大家都张扬个性，那么代码将会是一团糟，好好的项目就被糟践了。不管是开发还是日后维护，都将是灾难。
这时候，有人提出了何不统一标准，大家都按照这个标准来。于是 ESLint，JSHint 等代码工具如雨后春笋般涌现，成为了项目构建的必备良品。
Git Commit 规范可能并没有那么夸张，但如果你在版本回退的时候看到一大段糟心的 Commit，恐怕会懊恼不已吧。所以，严格遵守规范，利人利己。

二、具体规则

先来看看公式：

():
type
用于说明 commit 的类别，只允许使用下面7个标识。

feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style： 格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动
scope

用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

subject

是 commit 目的的简短描述，不超过50个字符。
以动词开头，使用第一人称现在时，比如change，而不是changed或changes
第一个字母小写
结尾不加句号(.)

三、异常处理

我们先来看看这个异常提醒：

INVALID COMMIT MSG: does not match "(): " !
jartto:fix bug
这里之所以报出这个警告，是因为我的提交出现了两个问题：

其一，使用了规范外的关键字;
其二，很细节的问题，jartto：后少了空格;
这时候我才回忆起来，当时提交一直失败，情急之下直接强制提交，所以以后的提交都会抱出这个异常。大致意思就是：
你的之前的 Commit 不合格～你的之前的 Commit 不合格～你的之前的 Commit 不合格
这时候就很烦了，我们只能去将之前的错误修正，那么如何操作呢?

四、如何修改之前的 commit 信息？

其实并不复杂，我们只需要这样做:

1、将当前分支无关的工作状态进行暂存

git stash

2、将 HEAD 移动到需要修改的 commit 上

git rebase 9633cf0919^ --interactive

3、找到需要修改的 commit ,将首行的 pick 改成 edit

4、开始着手解决你的 bug

5、 git add 将改动文件添加到暂存

6、 git commit –amend 追加改动到提交

7、git rebase –continue 移动 HEAD 回最新的 commit

8、恢复之前的工作状态

git stash pop

大功告成，是不是想把整个 Commit 都修改一遍