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