Why

1. 在接手新项目时候

• 你希望看到git的commit记录是这样的?

  
  image.png

• 还是这样的?? WTF!?

  
  image.png

2. 听说鱼的记忆只有7秒钟, 但是我看人的记忆也不怎么样,反正我能记清楚之前写的代码细节,最多只有7天
3. 那么问题来了,git提交记录如果不能提供有效信息,项目上线一段时间之后出bug需要修复,或者临时接手其他同事项目时,看到git记录里只有一堆的Update心情如何?

What

• git 提交commit部分,规范模板,提供尽量详细的信息
• 用最少得话把事说清楚,格式统一,方便快速阅读和定位
• 不用想太多，简洁操作 , 无需额外增加大量时间
• 与gitlab数据issue关联，获取更多信息, 例如当时这个需求细节是怎么样的?或者客户提出了什么样的奇葩要求,才有这段shi~一样的代码?

How

• 复制模板(之后分享这个文件)到你的home目录.
• 执行命令: git config --global commit.template ~/.git-commit-template
• 看一下是否正确配置了: git config commit.template
• 每次体检时简单修改一下即可,一般不会超过1分钟
• 举一些完成的例子:
  1.<修改>: (后台MGTOMedia/AppBundle/Controller/NewsController.php) <为了保持前后台新闻排序一致,这里统一修改为按照position desc > issue#17
  2.<bug修复>: (MGTOMedia/CommonBundle/Services/ElasticSearchService.php)<搜索的queryBuilder忘記跟著改過來了,这里统一改一下> issue#18
  3.<测试代码>: (尝试composer引入phpoffice)composer 引入phpOffice读取doc文件遇到一些问题
  4.<文档改动>: (新增文档) <ElasticSearch相关>新增Ela搜索News的Mapping文档和搜索使用的query例子伪代码
• 如果你针对自己的模板有什么改进,请记得分享给我一份!
• 我的文档范本: (你看,真的很简单,只有3行)

<新功能|bug修复|文档改动|格式化|重构|测试代码>: (影响范围) <主题> 
# 解释为什么要做这些改动
issue #?

How good

• 总结我个人在2018年下半年使用情况来看,这个确实是有必要的.几乎不花费额外精力和时间,但是之后查找问题效率很高.
• 可以通过 issue#? 关联到gitlab. 这样如果之前关于每个需求细节都在issue中讨论的话,那么这几乎就是一套非常完整而且有细节,有代码的项目文档了.也不需要额外花费时间来写文档. 我知道写文档这工作基本没人愿意做. 等到真的需要的时候,也没人能记得清楚到底该写什么了.
• 写清关联信息，方便事后查找，同事协作
• 别给自己挖坑，提高问题解决的效率
• 合作的时候能快速理解一些设计的原因
• 出问题的时候可以快速定位到位置，并且理解逻辑快速修正
• 你不能确保自己能在一个月后，自己还能记住项目的每个细节

最后,附上思维导图(2.2MB)

image.png