忽略标题先，只是觉得一个 createDeedReportForPlan 修改了 11 次，没有人抓 git 提交记录的吗？我们这里要是谁这么频繁的提交代码，他的代码绝对会被例会全组 review，是写的多烂啊。

屎山

我就喜欢频繁提交代码，提交的代码说明是想要的，有时候大量代码没提交，中途又觉得有些代码不满意，手动回滚太麻烦，还容易出错。对于一个稳定的运行的项目，小范围提交不至于破坏性太大。

根本说的不是同一个问题，频繁提交代码修复 bug 反应出来的是一个程序员本身的素质问题，和你是不是想最小范围 merge 代码是两件事情。
1、这个人没有做单元测试的习惯，在一个没有审核 merge 的 git 环境下对其他人简直是灾难。
2、体现了你代码结构有本质的问题，你的代码更加难以阅读，流程控制更加难以理解，问题更加难以发现，以至于你自己都不能清晰的发现代码本质问题在哪里。所以才会出现频繁提交代码的结果，如果一个结构清晰，命名明确，各个方面都良好的代码怎么会需要改这么多次？
3、再不然就是你自己本身就不理解代码在干什么，ctrl+c 了一段代码，真正跑起来才知道原来这里并不通用，然后就一直修改提交，修改提交，修改提交。

应该要在研发内部推广一下 git rebase，把无效的 commit 合并在一起，这样提交记录才干净且可 review
参考：http://jartto.wang/2018/12/11/git-rebase/

你可以选择不看撒，又不是构建一次你就要测一次，如果真的是，让他们给个提测申请，按你的要求让他们填，自己就会降低构建次数了。

版本构建是做什么用的？版本说明？

从效率上说，确实直接把代码提交记录复制过来是最简单的。我们 Jenkins 每次构建的内容差异，也是主要查看相比上次构建，代码变更记录来判定的。虽说也有可能让开发自己再写细一些，但对于一天构建几次甚至十几次的频率来说，每次这么写太费时间了，而且颗粒度、准确度相比直接查看代码提交记录来说，更难保障。

不知道楼主想要的是什么效果呢？