Why

在接手新项目时候

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

还是这样的?? WTF!?

听说鱼的记忆只有7秒钟, 但是我看人的记忆也不怎么样,反正我能记清楚之前写的代码细节,最多只有7天

那么问题来了,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) issue#17

2.: (MGTOMedia/CommonBundle/Services/ElasticSearchService.php) issue#18

3.: (尝试composer引入phpoffice)composer 引入phpOffice读取doc文件遇到一些问题

4.: (新增文档) 新增Ela搜索News的Mapping文档和搜索使用的query例子伪代码

如果你针对自己的模板有什么改进,请记得分享给我一份!

我的文档范本: (你看,真的很简单,只有3行)

: (影响范围) # 解释为什么要做这些改动issue #?

How good

总结我个人在下半年使用情况来看,这个确实是有必要的.几乎不花费额外精力和时间,但是之后查找问题效率很高.

可以通过 issue#? 关联到gitlab. 这样如果之前关于每个需求细节都在issue中讨论的话,那么这几乎就是一套非常完整而且有细节,有代码的项目文档了.也不需要额外花费时间来写文档. 我知道写文档这工作基本没人愿意做. 等到真的需要的时候,也没人能记得清楚到底该写什么了.

写清关联信息，方便事后查找，同事协作

别给自己挖坑，提高问题解决的效率

合作的时候能快速理解一些设计的原因

出问题的时候可以快速定位到位置，并且理解逻辑快速修正

你不能确保自己能在一个月后，自己还能记住项目的每个细节

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

-END-