写mit?message提高业务效率的方法
本篇文章和大家了解一下写mit message提高业务效率的方法。有一定的参考价值，有需要的朋友可以参考一下，希望对大家有所帮助。
这个很多时候很头疼，大mit 不好 review，每次一看到十几个文件上千行记录在一个mit 里就很想哭。小mit 本身是没问题的，但很多时候大家稍微改一点就提一个mit，导致放眼望去全是意义不大的提交，记录基本没法看。
怎么把握这个度呢？
这里提供一个标准供大家参考：你的mit 能得体地告诉别人干了一件什么事。
一件事
能拆的要拆，两个语义独立的改动不要放到一个mit 里面，做好一件事即可mit 的内容应该是高内聚的，不要出现夹带私活的情况。
只要保证你的 Merge Request 是干净的，信息清晰的就 ok，不要担心一个 MR 对应多个mit 的问题，该合并就合并，但语义独立的两件事，不要合在一起写。
得体
不要随随便便改一个地方就提交一次，比如这里加了个空行，那里删了个注释，全拆开，倒的确是不同的事，但这样让别人看就很不得体。想象一下，你现在是个教练，本来可以等学员练习好了，看一遍效果给出评价即可，可你的学生每做一个动作就要把你拉过来看看，这时你是什么心态？肯定要崩溃！
软件开发也是如此，明明你是要开发一个需求，结果只有一个mit 是真正支撑需求的，各种格式优化的mit 多达十几个，这就非常不得体。
思考每一个mit 是否必须。一定要记住，不要多写一行多余的代码，否则未来你会很纠结；
学会归纳。合并同类项。
message 格式
<type>(<scope>): <subject> <空行> <body> <空行> <footer>
type
type 就是mit 的类型：
docs: 文档变更
feat: 新需求特性
fix: 修复 bug
perf: 性能提升
style: 代码风格相关
test: 测试代码修改
refactor: 重构代码
chore: 构建过程或辅助工具的变动，日常的修改
scope
scope用于说明mit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。这个大家根据业务情况自行约定规范即可。
subject
body
对本次mit 的详细描述，可以分成多行，说明代码变动的动机，以及与以前行为的对比，详细的背景要在这里说清楚。比如
More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. Further paragraphs e after blank lines. - Bullet points are okay, too - Use a hanging indent
只有在 break change 或者关闭 issue 时使用，场景较少，日常业务开发可以忽略。事实上，能把 subject，body 写好就不容易了。
内容多了怎么办
很多时候大家都直接用 gitmit -m "xxx" 来代替，其实建议大家带上 body，很多mit 光看 subject 跟没看是一样的。
这种情况下，大家直接用 gitmit 来提交，跳出文本编辑器，支持大家输入 body。
一定记住，body 不是可有可无，一个优秀的mit message 要能做到看了就知道前因后果，知道改动原因。而不是留一句片汤话在 subject 上。
语言选择
这一点很多团队会忽视，笔者待过的几乎每个团队，都是中英文混杂，这一点很不好。建议统一语言，如果公司规定开发必须用【英语】，ok 没问题，大家做好准备，提高英语素养，找到每个业务概念最精准的表达，形成规范，落地就行。
但是，但是！！！
绝大多数团队是做不到这一点的，因为没有动力，而且大家都是中国人，很多语言表达即便过了四六级，也很难很精准，于是写的五花八门。
与其这样，不如明确，除了 type，其他全用中文代替。
以上就是写mit message提高业务效率的方法的简略介绍，当然详细使用上面的不同还得要大家自己使用过才领会。如果想了解更多，欢迎关注测速网www.inhv.cn行业资讯频道哦！
向AI问一下细节上一篇：JavaScript中WeakMap的原理与用法介绍
