共计 1164 个字符，预计需要花费 3 分钟才能阅读完成。
其实对于这个问题，老早都想整顿了，只是始终没有腾出空来，最近刚好有空，索性整顿了下。
这里就不过多介绍什么是 Git 了，本文的重点是 Commit Log，如果还不分明Git 是什么，能够看一下我的 Git 系列的其余笔记。
为什么要关注提交信息
- 放慢
Reviewing Code的过程 - 揭示本人或别人，某个提交具体减少了什么性能，改变了哪些地方
- 进步我的项目的整体品质
Angular 标准的 Commit message 格局
这种格局（标准）是我目前感觉绝对其余格局（标准）而言，最容易接受、上手的一种。
其外围是每次提交，Commit message 都包含三个局部：Header，Body 和 Footer。
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>其中，Header 是必须的，Body 和 Footer 能够省略。
Header
Header 局部只有一行，包含三个字段：type（必须）、scope（可选）和 subject（必须）。
type 用于阐明 commit 的类别，只容许应用上面几个标识：
- feat 新性能（feature）
- fix 修补 bug
- docs 文档（documentation）
- style 格局（不影响代码运行的变动）
- refactor 重构（即不是新增性能，也不是批改 bug 的代码变动）
- test 减少测试
- chore 构建过程、辅助工具的变动
- perf 进步性能
- typo 打字谬误
scope 用于阐明 commit 影响的范畴，比方数据层、管制层、视图层等等，视我的项目不同而不同。
subject 是 commit 目标的简短形容，不超过 50 个字符。
Body
Body 局部是对本次 commit 的详细描述，能够分成多行。
Footer
Footer 局部只用于不兼容变动和敞开 Issue。
总结
原本我本人始终应用的形式就是：git commit -am "fix login bug"，尽管并没有相对的对错，但这显然不是最好的形式。
这种货色并没有强制性的规定，只有团队之间约定好，而后依照这个约定合作就好了。
所以我感觉在团队之间 commit 时，能够不必齐全依照 Angular 标准的 Commit message 格局去提交，能够依照以下约定来执行。
commit时，只用保留 Header 局部就好。pull request时，才须要 Header、Body、Footer 这三局部。
另外 commit 时须要留神以下几点：
- 创立短小而明确的
commit，一句话说分明。 - 一个小改变对应一次
commit，不倡议一大堆改变，一次commit。 - 如果增加的代码会使我的项目产生极大的变动，那么须要及时更新
remade文件以向别人阐明此次更改。
最佳实际
docs: add FAQ in readme file
feat: increase user login function
fix: fix user login bug
正文完
