如何将"版本控制"与R的"工作流程"结合起来？

我记得R用户写过他们使用"版本控制"(例如:"源代码控制"),我很想知道:你如何将"版本控制"与统计分析工作流程结合起来？

两个(非常)有趣的讨论谈论如何处理工作流程.但它们都没有引用修订控制元素:

如何组织大型R程序？

统计分析和报告编写的工作流程

对问题的长期更新:根据一些人的答案,以及评论中的Dirk的问题,我想更多地指出我的问题.

在阅读了关于" 版本控制 " 的Wiki文章(我以前不熟悉)之后,我很清楚,在使用版本控制时,我们所做的就是构建他的代码的开发结构.这种结构要么导致"最终产品",要么导致几个分支.

当建立类似的东西时,比方说,一个网站.通常有一种最终产品(网站),一路上有一些原型.

但在进行统计分析时,工作(我认为)是不同的.有时你知道你想去哪里.但更多时候,你会探索.探索清理数据集.探索不同的统计分析方法,并询问您的数据的各种问题(我正在写这篇文章,了解Frank Harrell和其他经验统计学家对数据挖掘的看法).

这就是为什么统计编程的工作流程问题(在我看来)是一个严肃而深刻的问题,引发了许多问题,更简单的问题是技术问题:

您使用哪种版本控制软件(及其原因)？

你使用哪个IDE(以及为什么)？更有趣的问题是关于工作流程:

你如何构建你的文件？

你作为一个单独的文件和什么作为修订保留？或以不同的方式询问 - 什么应该是"分支",什么应该是你的代码中的"子项目"？例如:在开始探索数据时,是否应该创建一个绘图然后删除,因为它不会导致任何位置(但保留为修订版)或者是否应该存在该路径的备份文件？

如何你解决这种紧张是我最初的好奇.第二个问题是"我可能会缺少什么？".应该遵循哪些(经验)规则,以避免使用版本控制进行统计编程时常见的陷阱？

在我的直觉中,我觉得统计编程本质上与软件开发不同(我写的不是统计编程的真正专家,在软件开发中更是如此).这是我不确定我在这里阅读的关于版本控制的哪些课程将适用的方式.

非常感谢,Tal

我的工作流程与Bernd没有什么不同.我通常有一个主目录,我把所有*.R代码文件放在那里.一旦我在文本文件中有超过5行,我就开始版本控制,在我的情况下是git.我的大部分工作都不在团队环境中,这意味着我是唯一一个改变我的代码的人.一旦我做出实质性的改变(是的,这是主观的)我就会办理登机手续.我同意Dirk的说法,这个过程与工作流程是正交的.

我使用Eclipse + StatET,虽然Eclipse中有一个git插件(EGit和其他人),但我没有使用它.我在Windows中,只是在Windows上使用git-gui.这里有更多选择.

版本控制中存在很多个人特质的空间,但我建议将这一小贴士作为最佳实践:如果您向其他人报告结果(即期刊文章,您的团队,公司管理层),请始终进行版本控制检查在运行结果给别人之前.3个月之后,总会有人会查看您的结果并询问一些您无法回答的代码问题,除非您在生成这些结果时知道代码的确切状态.因此,请将其作为一种做法,并在评论中加入"这是我用于第四季度财务的代码版本"或任何用例.

另请注意,版本控制不能替代良好的备份计划.我的座右铭是:"3份.2个地理位置.1个心灵平静."

EDIT(2010年2月24日): Stack Overflow的创始人之一Joel Spolsky刚刚发布了一个高度直观且非常酷的介绍Mercurial.如果您尚未选择修订控制系统,则本教程可能是采用Mercurial的理由.我认为当谈到Git vs. Mercurial时,最重要的建议是选择一个并使用它.也许使用你的朋友/同事使用的东西或使用最好的教程.但只需使用一个!;)

而不是特别关注版本控制,听起来你真的在问一个关于统计分析如何与软件开发进行比较的更大问题.这是一个有趣的问题.以下是一些想法:

数据分析可以更像是一门艺术,而不是一门科学.从某种意义上说,您可能希望寻找作者在编写书籍时所遵循的流程的灵感,而不是软件开发人员遵循的流程.另一方面,我还没有遇到一个直线的软件项目.即使在理论层面,软件开发方法也存在很大差异.其中,考虑到统计分析可以发现过程(即一个不能完全计划前面),它将使意义遵循类似的敏捷方法(更使像瀑布方法).换句话说,您需要计划您的分析是迭代和自我反思.

也就是说,我认为统计分析纯粹是探索性而没有目标的概念可能存在问题.这可能导致你超过尤里卡时刻的5步,并且无法回到它.即使目标本身正在改变,总会有某种目标.而且,如果没有目标,你怎么知道什么时候到达终点？

一种方法是在启动项目时启动一个R文件(或者像Josh和Bernd示例中的一组文件),并在发现时逐步添加(以使其增大).当您需要将数据保留为分析的一部分时,尤其如此.此文件应定期进行版本控制,以确保在出错时始终可以倒退(允许增量增益).版本控制系统在开发过程中非常有用,不仅因为它们确保您不会丢失任何东西,还因为它们为您提供了时间轴.并标记您的签到,以便您一目了然地了解其中的内容,并注意主要的里程碑.我喜欢JD关于在提交内容之前办理登机手续的要点.

一旦得出最终结论,通常最好创建一个文件的最终版本,从头到尾总结您的分析.您甚至可以考虑将其放入Sweave文档中,以使其完全独立且有文化.

你还应该认真考虑周围的人在做什么.没有什么能比让人们重新发明轮子更让人畏缩,特别是当它意味着整个集团的整体工作需要额外的工作时.

您对使用哪个版本控制系统,哪个IDE等(实施问题)的决定最终在整个项目管理的图腾柱上极低.只要正确地使用它们中的任何一个,你已经有95%的方式,并且与使用任何东西的替代方案相比,它们之间的差异很小.

最后,如果你使用像github,谷歌代码或者R-forge这样的东西,你会发现它们都有一些共同之处:除了版本控制系统之外的一套工具.也就是说,您应该考虑使用诸如问题跟踪系统和维基之类的内容来记录进度并记录打开的问题/任务.分析越有条理,成功的可能性就越大.

我正在使用git进行版本控制.我的典型目录结构(例如文章)如下.

.
..
.git
README
README.html
ana
dat
doc
org

大多数目录/文件(ana,doc,org)都受版本控制.当然,大型二进制数据集从版本控制中排除(通过.gitignore).README是一个Emacs组织模式文件.