偶尔也要发一篇不是废文的 (希望不是 @rz)
==========================================
先说请客就不用了 @@"
==========================================
上面推文说到要知道目前用什么、怎么用，
这样才有方向提供资料。
也提到主管喜好，这里的喜好是指他有没有偏爱的功能，
Ex
他超爱 CVS lock 觉得这样都不必解 conflict 好棒棒
那...Git 没有 XD
就得想怎么 workaround 或说服他
==========================================
看你之前的文我猜是 CVS -> Git
那就...
Git VS CVS
http://ppt.cc/VwAN
答案就不错，要量化的点也容易，
开一个 repo 的步骤/时间，
开一个 branch 的步骤/时间，
CVS 操作时发生失败状况的修复步骤/时间 (vs Git 操作发生失败也没差)
转换心得
http://ppt.cc/t~iK
蛮风趣的，6. 7. 9. 三点应该可以用。
use case
http://ppt.cc/@@d5
之前板上有人分享过，
不过还是要看你们专案的状况，不见得能用很顺。
若主管超中意 lock 看这篇能不能挣扎一下
http://ppt.cc/xdlt
Since (AFAIK) the Subversion locks are just advisory,
an e-mail or instant message could serve the same purpose.
But even if you don't do that, Git lets you fix it.
(哞哩洗咩按怎...XD)
不然非要 lock 不可的话还得要有一个人负责管权限，
每次谁要改哪个档就开要改的人的权限并关其他人的，
搞到这样反而更麻烦...
另外也因为没 lock，Git 的操作流程要先想好，
什么情况下遇到 conflict 时要怎么处理，
例如由当下遇到的人负责解掉，或提出讨论，
或其它。
==========================================
另外建议可以把操作录成影片，
平常用 CVS 会用的操作都录，
CVS 版跟 Git 版各录一个。
开 repo 各录一个，branch 各录一个，
merge 各录一个这样分开来录，
简报的时候放来看，
这样一比影片长度就很清楚效益怎么样，
看影片步骤就很清楚哪个容易哪个麻烦，
应该会比静态图文有感得多。
录的工具可以用 screen recorder 或 Jing (应该还是免费)
不然估狗一下 record screen 也有很多别的工具。
EDIT: 20140729
==========================================
另外补充一点
请确定你的主管有兴趣知道，
以及弄清楚为什么一直固守 CVS
例如假如一直固守 CVS 的原因是主管的主管有什么高见的话，
那你报告的越好有可能是越让主管的主管难堪
(AKA 可能不是什么好事)
总之，以技术研究报告的角度去做，
报告完就算了，这样可能会比较好？
※ 引述《dream1124 (全新开始)》之铭言：
: 请问大家可以分享适合在整理后拿给主管看，推荐使用 git 的文章吗？
: 在受够公司功能差的版控系统和古怪的提交工作流程后，
: 小弟终于得到一个机会，能向上级建议使用 git。
: 只是有关 git 的介绍及相关的提交工作流程讨论文章实在太多，
: 既不可能也不适合在一两次简短的简报中一口气地塞给主管，
: 我打算在报告中挑出少数够经典，够震撼的内容，
: 用少量但很具体能打动人心的项目，影响他们的决定。
: 主管们从不觉得新技术新功能有什么，对画大饼式的说法也不感兴趣，
: 他们只在意用不用得到，需不需要，能降低多少成本产生多少效益，
: 最好能数字量化。然后东西多半是能用就好，有就好。
: 至于那些潜在能大幅影响生产力的因素，像是某些让基层工作更愉快更有弹性的做法
: 或是工具，在主管眼中因为比较难观察到效果且量化为个人绩效，
: 因此通常都当作不存在。
: 想请问大家，对于这类型的主管可否推荐什么好文章，让我撷取重点给主管们看吗？
: 如果您推荐的好内容之后能影响主管，使我们可以使用 git
: 小弟愿在事成之后请客，谢谢大家帮忙囉~