Git commit是代码提交时必经之路，commit虽然没有具体的规范，但也不能太过于随意，不然当你回头浏览git仓库的日志时，也可能会一脸懵逼（小编就曾经被点名，都怪小编当年过于放荡不羁 ￣□￣｜｜ ）

下面小编总结了一些Tips：

1、one thing one commit

在提交commit的时候尽量保证这个commit只做一件事情，比如实现某个功能或者修改了配置文件。

这样会有几个好处：

• 易读 ：阅读整个项目代码的时候有时候整个项目通读并不是一个好的方法。我们可以通过 issue 或者 commit 来一点一点分解整个 repo。如果一个 commit 只聚焦在一个点上，那么代码看起来也会比较舒服，顺着 commit 读下来就是当初的开发过程了。
• cherry-pick ：cherry-pick 是 git 中的一个非常有用的命令，可以将 commit 从一个分支“拷贝”到另一个分支。如果我的 commit 划分都很清楚，那么 cherry-pick 就会比较轻松。但是如果我的一个 commit 即实现了功能A，又实现了功能B，而我只想要功能A，这就很尴尬了。
• code review : review 过别人代码的人都知道如果 commit 乱七八糟那将有多么痛苦。如果commit msg写得清晰就可以方便代码的阅读。

# 50-character subject line
# 72-character wrapped longer description. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
# Include a link to the ticket, if any.
文章《5 Useful Tips For A Better Commit Message》中是这样规定：
 
 
第一行不超过50个字符；
第二行空一行
第三行开始是描述信息，每行长度不超过 72 个字符，超过了自己换行；
描述信息主要说明：
 
（1）这个改动为什么是必要的？
 
（2）这个改动解决了什么问题？
 
（3）会影响到哪些其他的代码？
最后最好有一个相应的ticket的链接
 
​当Commit主题不超过50个字符，然后空一行，这样显示的下面的部分都会折叠起来，类似下面的样子。我们使用命令 git log --oneline的时候就只显示第一行。正文部分不超过 72 个字符，也主要是为了阅读方便。关于最后的一个 ticket 的说明。我们开发之前需要将所有的功能进行拆解，然后开发过程中需要通过一些工具来 track ，每个小功能就是一个 ticket。有些公司使用 jira，有些公司使用 wiki。以使用 jira 为例，前面把功能拆解之后分到每个人手上。这样我们进行提交的时候附上对于的 ticket 链接或者 ticket 号，之后再回溯的时候就会非常方便了。或者也可以给 jira 开发插件，通过抓取 git commit 信息进行分析就能将相应的改动代码直接展示在 jira 上了。这么做的好处不言而喻，需求-功能-开发-代码，整个都被串起来了，不管是对于新人了解系统还是5年或者10年之后回溯都是非常有帮助的。
 
AngularJS社区的commit msg包括三个部分：header, body, footer。
 
revert： 如果这个commit revert (回滚)了别的 commit，那么它的 header 应该以 “revert:”开始，后面跟上被 revert 的 commit 的标题。body 应该是 This reverts commit .
header: header应该包括type，分隔符，主题。
 
type主要包括：
 
​ feat(feature) 
 
​ fix(bug fix) docs(documentation) 
 
​ style(formating,missing semi colons,…) 
 
​ refactor 
 
​ test(when adding missing tests) 
 
​ chore(maintain)
 
主题信息能够简短地描述你的 commit 即可，结尾不要使用“.”，开头首字母不要大写。使用祈使语态，比如使用 change，而不是 changed。
msg body：除了 header 的主题信息的要求外，还需要包括为什么要做这个 commit，以及改动前后的对比。
footer：
 
​ Breaking changes：重要的改动要声明 (可以放在header)
 
​ Referencing issues：如果和 issue 相关，指出来。
 
下面请看一个正确的栗子：
 
fix($compile): couple of unit tests for IE9
Older IEs serialize html uppercased, but IE9 does not...
Would be better to expect case insensitive, unfortunately jasmine does
not allow to user regexps for throw expectations.
Closes #392
Breaks foo.bar api, foo.baz should be used instead
 
4、实践篇（超实用）
 
（1）用一个空行隔开标题和正文
 
来自 git commit 帮助页：
 
 
虽然不是必须的，在提交的信息中先用一行简短的文字（少于50个字符）总结改动是好的想法，后面空一行就是更为详细的描述。提交信息中第一个空行前的文字可以作为题目，这个题目会在整个 Git 用到。比如，git-format-patch 把一个提交转化成 email，它就使用这个题目作为邮件的标题，提交中余下的部分作为邮件正文。
 
如果提交的信息像下面命令行那样简单，你可以在 git commit 时使用-m 开关。
 
$git commit -m "Fix typo in introduction to user guide"
 
但如果一个 commit 需要多解释一点，你就要写一下正文。
 
在浏览日志时，你会发现把标题和正文分开是值得的。下面是完整的日志：
 
$git log 
commit 42e769bdf4894310333942ffc5a15151222a87be
Author: Kevin Flynn <kevin@flynnsarcade.com>
Date:   Fri Jan 01 00:00:00 1982 -0200
 Derezz the master control program
 MCP turned out to be evil and had become intent on world domination.
 This commit throws Tron's disc into MCP (causing its deresolution)
 and turns it back into a chess game.
 
现在执行 git log –online，就只印出主题这行：
 
$git log --oneline
42e769 Derezz the master control program
 
或者，git shortlog，按用户来归类提交信息，为了简洁一样也只显示标题。
 
$git shortlog
Kevin Flynn (1):
      Derezz the master control program
Alan Bradley (1):
      Introduce security program "Tron"
Ed Dillinger (3):
      Rename chess program to "MCP"
      Modify chess program
      Upgrade chess program
Walter Gibbs (1):
      Introduce protoype chess program
 
（2） 限制标题文字在50个字符内#####
 
​ 50个字符不是一个硬性规定，只是一个经验之谈。把标题行限制在这个长度，既保证它们容易阅读，也强迫作者去思考如何用最精简的方式解释发生了什么。
 
（3）用大写字母写标题行
 
​ 标题行的首字母大写：
 
​ 例如：Accelerate to 88 miles per hour
 
​ 而不是：accelerate to 88 miles per hour
 
（4）不要用句号结束标题行
 
​ 标题行不需要考虑标点符号。而且如果希望保持在 50 个字符以内，慎用空格。
 
（5）在标题行使用祈使语气
 
​ 祈使语气就是像给一个命令或指示一样叙述或写作。
 
​ 祈使语气听起来有点粗鲁；所以我们通常不使用它。但对 git 提交信息的标题行而言，它确实很棒。一个原因是当 git 代表你创建一个提交时，它自己就是使用祈使语气。
 
例如，使用git merge 后的默认输出信息读起来就像：
 
Merge branch 'myfeature'
 
当你使用git revert时：
 
Revert "Add the thing with the stuff"
This reverts commit cc87791524aedd593cff5a74532befe7ab69ce9d.
 
或者当在一个 GitHub pull请求上点击“Merge”按钮时：
 
Merge pull request #123 from someuser/somebranch
 
当你用祈使语气编写你的提交信息时，你遵守了 git 内在的约定。例如：
 
重构 X 子系统以增加可读性
更新新手入门的文档
删除弃用的方法
发布1.0.0版本
 
一开始这样写会有点尴尬。同样是用来描述事实，我们更习惯用陈述方式去讲话。这也就是为什么提交信息常常读起来都是这样：
 
==用 Y 修正了问题==
==X的改变行为==
==对损坏事物的更多修正==
==新酷的 API 方法==
 
一个格式正确的 git 标题行应该可以完成下面的句子： 
 如果被采用，这个 commit 将把你的标题放在这里
 
例如：
 
  
如果被采用，这个 commit 将会重构 X 子系统以增加可读性
如果被采用，这个 commit 将会更新新手入门的文档
如果被采用，这个 commit 将移出弃用的方法
如果被采用，这个 commit 将发布 1.0.0 版本
如果被采用，这个 commit 将从 user/branch 合并 #123 pull 请求
 
注意下面这些非祈使格式不能工作：
 
  
如果被采用，这个 commit 将用 Y 修正了问题
如果被采用，这个 commit 将X 的改变行为
如果被采用，这个 commit 将对损坏事物的更多修正
如果被采用，这个 commit 将新酷的 API 方法
 
记住：使用祈使语气只在标题上是重要的。你在编写正文的时候，可以放宽这一限制。
 
（6）正文在72字符出换行
 
​ Git 从来不自动换行。当你编写一个提交信息的正文时，你必须考虑到正确的间距和手动换行。推荐在72个字符处换行，这样 git 有足够的空间来缩进文本，还可以保持整体都在80个字符以内。
 
（7）使用正文解释是什么和为什么，而不是如何做
 
​ 这个提交是一个来自 Bittcoin Core 的好例子，解释了什么被改动了和为什么：
 
commit eb0b56b19017ab5c16c745e6da39c53126924ed6
Author: Pieter Wuille <pieter.wuille@gmail.com>
Date:   Fri Aug 1 22:57:55 2014 +0200
   Simplify serialize.h's exception handling
   Remove the 'state' and 'exceptmask' from serialize.h's stream
   implementations, as well as related methods.
   As exceptmask always included 'failbit', and setstate was always
   called with bits = failbit, all it did was immediately raise an
   exception. Get rid of those variables, and replace the setstate
   with direct exception throwing (which also removes some dead
   code).
   As a result, good() is never reached after a failure (there are
   only 2 calls, one of which is in tests), and can just be replaced
   by !eof().
   fail(), clear(n) and exceptions() are just never called. Delete
   them.
 
​ 大多数情况下，你可以省去改动的具体实现细节。 在这点上，代码通常是不需加以说明的（如果代码太复杂需要文字解释，可以使用代码注释）。首先把你做这个改动的原因交待清楚 —— 改动前是如何工作的（和出了什么问题），现在是如何工作的，以及为什么你要采用这种方法解决问题。
 
未来的维护者会感谢你，这个人可能就是你自己！
                    Git commit是代码提交时必经之路，commit虽然没有具体的规范，但也不能太过于随意，不然当你回头浏览git仓库的日志时，也可能会一脸懵逼（小编就曾经被点名，都怪小编当年过于放荡不羁   ￣□￣｜｜  ）                     下面小编总结了一些Tips：1、one thing one commit在提交commit的时候尽量保证这个commit只做一件事情，比如实现某个功
				
1.  用命令行的git提交代码时，  我通常用 git  commit  -m  "1. 我是代码log"， 但是一直不知道怎么写多行log
     网上说， 可以用单引号来写多行commit， 试了试一直没成功
2. 后来找了同事， 同事那里可以成功， 他是在linux下提交代码的， 提交代码时类似这样
如果你曾经开过任意一个Git仓库的提交历史，你可能会发现它们的提交信息多多少少会有些混乱。
请比较下面两个提价历史：
$ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009"
e5f4b49 Re-adding ConfigurationPostProces