R如何将“修订控制”与“工作流程”结合起来使用？

Question

我记得有过R用户写过他们使用“修订控制”（e.g: "Source control"），我很想知道：您如何将“修订控制”与统计分析工作流结合起来？

两个（非常）有趣的讨论讨论如何处理工作流程。但无论他们的参考版本控制元素：

• How to organize large R programs?
• Workflow for statistical analysis and report writing

长期更新的问题：按照一些人的答案，和德克的问题在评论，我想多指导一下我的问题。

念叨“revision control”维基文章（我以前不熟悉）之后，很明显，我认为使用版本控制时，什么人做的是打造自己的代码发展结构。这种结构要么导致“最终产品”，要么导致多个分支。

当我们建立一个类似网站的时候，通常有一个最终产品正在朝着（网站）方向努力，同时还有一些原型。

但是当做统计分析时，工作（在我看来）是不同的。有时你知道你想去的地方。但更多的时候，你会探索。探索清洁数据集。探索不同的统计分析方法，并询问你的数据的各种问题（我正在写这篇文章，了解Frank Harrell和其他经验统计学家对Data dredging的看法）。

这就是为什么与统计编程的工作流程问题是（在我看来）一个严肃而深刻的问题，提出许多问题，越简单的有技术：

• 版本控制软件你使用哪种（和为什么）？
• 您使用哪个IDE（以及为什么）？ 更有趣的问题是关于工作过程：
• 你如何构建你的文件？
• 你作为一个单独的文件保存什么和作为修订？或以不同的方式询问 - 什么应该是“分支”，代码中应该是什么“子项目”？例如：当开始探索你的数据时，是否应该创建一个情节，然后抹去，因为它没有引导任何地方（但保留为修订版）或者应该有该路径的备份文件？

如何你解决这个紧张是我最初的好奇心。第二个问题是“我可能会错过什么？”。应该遵循哪些规则（拇指）以避免使用版本控制进行统计编程的常见缺陷？我认为统计编程与软件开发（我在编写这个时不需要真正的统计编程专家，甚至在软件开发中更少）编写本质上不同。这就是我不确定我在这里阅读的关于版本控制的哪些教训是适用的。

非常感谢， 塔尔

Answer 1

我的工作流程并不比贝恩德的不同。我通常有一个主目录，我把我所有的* .R代码文件。只要我有一个文本文件中的约5行以上，我开始版本控制，在我的情况下git。我的大部分工作不在团队背景下，这意味着我是唯一一个更改我的代码的人。只要我做出实质性改变（是的，这是主观的），我会进行检查。我同意德克认为，这个过程与工作流程是正交的。

我使用Eclipse + StatET，虽然有在Eclipse的git的插件（EGit和可能其他人），我不使用它。我在Windows中，只是使用Windows的git-gui。这里的some more options。

有很多的空间，在版本控制的个人特质，但我建议这个舌尖最佳做法：如果报告结果给他人（即杂志上的文章，你的团队，管理你的公司）ALWAYS做在运行结果发布给其他人之前的版本控制检查。不变的是，3个月后会有人看你的结果，并询问你不能回答，除非你知道代码的确切状态，当你产生这些结果代码中的一些问题。因此，请将其作为练习，并将其用于评论“这是我用于第四季度财务的代码的版本”或任何您的使用案例。

而且记住，版本控制是没有更换一个良好的备份计划。我的座右铭是：“3份，2个地理位置，1个和平的心灵。”

编辑（2010年2月24日）： Stack Overflow的创始人之一Joel Spolsky刚发布highly visual and very cool intro to Mercurial。如果您尚未选择修订版本控制系统，则仅凭此教程可能会采用Mercurial。我认为当谈到Git vs. Mercurial时，最重要的建议是选择一个并使用它。也许使用你的朋友/同事使用或使用最好的教程。但只是使用一个！ ;）

Answer 2

我使用的版本控制的git。我典型的目录结构（例如文章）如下。

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

大多数目录/文件（ana，doc，org）受版本控制。当然，大型二进制数据集不包括在版本控制中（通过.gitignore）。 README是Emacs组织模式文件。

Answer 3

我使用git，我自己。本地存储库，与R项目存储在同一目录中。那样，如果我在路上消除一个项目，仓库就会随之而来;我可以离线工作;我没有IRB，FERPA，HIPPA问题来处理。

，如果我需要增加备份的保证，我的git到远程（固定！）系统信息库。

-Wil

Answer 4

而不是专注于具体的版本控制，这听起来像你真的问如何统计分析比较，以软件开发一个更大的问题。这是一个有趣的问题。这里有一些想法：

数据分析可以是更像是一门艺术而不是科学。从某种意义上说，您可能希望寻找作者在写作本书时要遵循的过程，而不是软件开发人员要遵循的过程。另一方面，我还没有遇到一个遵循直线的软件项目。即使在理论层面上，software development methodologies也有很大的差异。其中，由于统计分析可以是一个发现过程（即不能预先完全规划的过程），因此遵循类似于agile methodology（更像瀑布方法之类的东西）是有意义的。换句话说，你需要计划你的分析是迭代和自我反思的。

这么说，我想的概念，统计分析是在考虑没有目标纯粹是试探性可能存在问题。这可能导致你超越你的灵光一刻5步，并且无法回到它。即使目标本身正在改变，总会有某种目标。而且，如果没有目标，你怎么知道你什么时候达到目的？

一种方法是在开始项目时（或者像Josh和Bernd示例中那样的一组文件），从一个R文件开始，然后逐渐添加到它（使其尺寸变大）发现。当您需要将数据保存为分析的一部分时，情况尤其如此。此文件应定期进行版本控制，以确保如果出现错误（允许增量增益），您总是可以退后一步。版本控制系统对开发非常有帮助，不仅因为它们确保您不会丢失任何东西，而且还因为它们为您提供时间线。并标记您的签入信息，以便您一目了然地了解其中的内容，并记下主要的里程碑。在提交内容之前，我喜欢JD的关于签入的观点。

一旦你已经达到了最后一组的结论，往往是最好的创建文件的最终版本，总结你的分析，从开始到结束。你甚至可以考虑把它放到一个Sweave文档中，以便它完全自包含和识字。

你也应该认真思考一下你周围的人在做什么。没有什么让我感到畏惧的不仅仅是看到人们重新发明轮子，特别是当它意味着为整个集团整合的额外工作时。

你要使用的版本控制系统决定，这IDE等（执行问题），最终都是在相对于整个项目管理的图腾柱极低。只需使用其中一个其中一个正确，你已经95％的方式，它们之间的差异很小，而不是使用什么的替代方案。

最后，如果你正在使用类似github上，谷歌代码，或R-锻造，你会注意到的东西，他们的共同点有：一套房不仅仅是一个版本控制系统的工具。也就是说，你应该考虑使用诸如问题跟踪系统和wiki这样的东西来记录进度并记录未决问题/任务。你对分析越有组织，成功的可能性就越大。

Answer 5

阅读你的更新后，好像你正在查看的选择和使用版本控制系统，作为口授结构和存储库的工作流程。在我看来，版本控制是更类似于一个保险，因为它提供以下服务：

1. 备份。如果意外删除了某些内容，或者命运匆匆将您的硬盘驱逐出去，那么您的工作可以从存储库中恢复。通过分布式版本控制，任何短缺的启示都可能导致你松动工作 - 在这种情况下，无论如何，你可能还有其他的事情需要担心。

2. 母亲所有的撤消按钮。分析在一小时前看起来好吗？一天前？一个星期前？版本控制提供了一个后退按钮，可让您及时回溯。

如果你是在一个项目上工作的唯一的人，以上两点可能勾勒出的版本控制系统将如何影响你的工作方式。

版本控制系统的另一方面是，他们通过允许人们对项目材料的独立副本或“分支”进行实验，然后将任何积极变化“合并”回主副本来培养协作努力。它还为项目成员提供了一种方法，可以监视哪些变更影响哪些文件的哪些行。

作为一个例子，我将版本控制下的所有大学课程保存在Subversion存储库中。我是唯一一个在此存储库上工作的人，所以我从不分支或合并源代码 - 我只是承诺并偶尔回放。将我的作品倒回的能力降低了尝试某种新分析的风险 - 我只是这样做。如果两个小时后，它看起来不是一个好主意，我只是恢复项目文件，尝试一些不同的东西。

相比之下，我的大部分非课程作业包/程序开发都在git之下。在这种设置中，我经常想在分支上进行实验，同时获得稳定的主副本。我使用git而不是颠覆在这些情况下，因为git使分支和合并一个毫不费力的任务。

重要的一点是，在这两种情况下我的仓库的结构和工作流程我用的不是我的版本控制决定系统 - 它们是由我决定的。版本控制对我的工作流程的唯一影响是，它使我免于担心尝试新事物，决定不喜欢它，然后必须撤消所有更改才能返回到我开始的位置。因为我使用的版本控制，我可以按照约吉贝拉的建议是：

当你在一个岔路口，把它。

因为我总是可以回头，并采取其他方式。