start_here/chap4/why_git_r.md

为什么要用GitR

贫僧是个保守主义者，不是万不得已，我是不鼓励创新的。创新需要太高的成本，只有喜欢穷折腾的无知无聊的人才会说什么创新永远在路上的胡话。新的想法看起来光鲜，往往十分的脱离实际，是头脑发热的产物，绝大多数是错的。新产品的不稳定性带来的烦恼往往比旧产品的功能局限带来的烦恼要多的多。而多数情况下，创新的动力并不是来源于改善旧产品功能的愿望，而仅仅是一种自以为科学的迷信教义或者积习难改人云亦云的随波逐流。这种漫无目的、杂乱无章的创新显然是没有价值的，甚至是很糟糕的行为。

不过，关于项目管理，却是到了万不得已的地步了。以我的亲身感受来说这个事也许更好些。

我们做项目，一定会有大量的文档，申报书、合同、通知、数据、图表、验收材料，回报材料，报奖材料，文章材料等，一大堆。我们会把同一个项目的文档根据文件类型或者时间或者功能类别进行分类，有经验的人会把它整理的井井有条，需要的时候能够快速定位的这个文件。而有些人（比如我）条理性差一些，没有定期整理的习惯。工作中的项目还好些，过了一段时间，在想找某个文件，就一篇茫然了。这个问题，很多人到现在还没有解决。这些人希望借鉴有条理的人的经验，最好是多个有条理的人的经验结合起来，形成一个更加有条理的更好用的结构，或者标准什么的，大家都照着他的办法做。再过分一点，最好能够自动生成，直接使用，不动脑子，动手也少，那多好。有了这么个标准，我的所有项目都这么做，日子久了，熟了，条件反射了，想要什么，不用想，不用翻，就知道它在哪儿。

这是个文件组织问题，没有GitR也能做到，有了GitR，可以实现自动生成。

有了高手的帮助，文件组织好了，试验做的不错，结题验收，还报了奖。有了基础，你又报了一个项目，建立在原来项目的基础之上，大部分的思路、方法、工作流程、分析方法都还原来一样。有时候为了弄点经费，可能原封不动的“克隆”一个项目，只是改改项目来源和项目标题而已（别说你没干过这事）。