我记得R用户写过他们使用“版本控制”（e.g: "Source control"），我很想知道：你如何将“版本控制”与统计分析工作流程结合起来？
两个（非常）有趣的讨论谈论如何处理工作流程。但它们都没有引用修订控制元素：
问题的长时间更新：根据一些人的回答以及Dirk在评论中提出的问题，我想更多地指出我的问题。
在阅读了关于“revision control”（我以前不熟悉）的维基文章之后，我很清楚，在使用修订控制时，我们做的是建立一个开发结构< / strong>他的代码。这种结构要么导致“最终产品”，要么导致几个分支。
当建立类似的东西时，比方说，一个网站。通常有一种最终产品（网站），一路上有一些原型。
但是在进行统计分析时，工作（在我看来）是不同的。有时你知道你想去哪里。但更多时候，你会探索。探索清理数据集。探索不同的统计分析方法，并询问各种数据问题（我正在写这篇文章，了解Frank Harrell和其他经验统计学家对Data dredging的看法）。
这就是为什么统计编程的工作流程问题（在我看来）是一个严肃而深刻的问题，引发了许多问题，更简单的问题是技术性的：
你如何解决这种紧张局势是我最初的好奇心。第二个问题是“我可能会缺少什么？”。应该遵循哪些（经验）规则，以避免使用版本控制进行统计编程时常见的陷阱？
在我的直觉中，我觉得统计编程本质上与软件开发不同（我写的不是统计编程的真正专家，在软件开发中更是如此）。这是我不确定我在这里阅读的关于版本控制的哪些课程将适用。
非常感谢， 塔尔
答案 0 :(得分：18)
我的工作流程与Bernd没有什么不同。我通常有一个主目录，我把所有* .R代码文件放在那里。一旦我在文本文件中有超过5行，我就开始版本控制，在我的情况下是git。我的大部分工作都不在团队环境中，这意味着我是唯一一个更改代码的人。一旦我做出实质性的改变（是的，这是主观的），我就会办理登机手续。我同意Dirk的说法，这个过程与工作流程是正交的。
我使用Eclipse + StatET，虽然Eclipse中有一个git插件（EGit，可能还有其他），但我没有使用它。我在Windows中，只是在Windows上使用git-gui。这是some more options。
版本控制中存在很多个人特质的空间，但我建议将这一小贴士作为最佳实践：如果您向其他人报告结果（即期刊文章，您的团队，公司管理层）总是< / strong>在运行结果发送给其他人之前执行版本控制检查。 3个月之后，总会有人会查看您的结果并询问一些您无法回答的代码问题，除非您在生成这些结果时知道代码的确切状态。因此，请将其作为一种做法，并在评论中加入“这是我用于第四季度财务的代码版本”或任何用例。
另请注意，版本控制不能替代良好的备份计划。我的座右铭是：“3份.2个地理位置.1个心灵平静。”
编辑（2010年2月24日）：Stack Overflow的创始人之一Joel Spolsky刚刚发布highly visual and very cool intro to Mercurial。如果您尚未选择修订控制系统，则本教程可能是采用Mercurial的理由。我认为当谈到Git vs. Mercurial时，最重要的建议是选择一个并使用它。也许使用你的朋友/同事使用的东西或使用最好的教程。但只需使用一个！ ;）
答案 1 :(得分：13)
而不是特别关注版本控制，听起来你真的在问一个关于统计分析如何与软件开发相比的更大问题。这是一个有趣的问题。以下是一些想法：
数据分析可以更像是艺术而非科学。从某种意义上说，您可能希望寻找作者在编写书籍时所遵循的流程的灵感，而不是软件开发人员遵循的流程。另一方面，我还没有遇到一个直线的软件项目。即使在理论层面，software development methodologies也存在很大的差异。其中，鉴于统计分析可以是一个发现过程（即一个前期无法完全规划的过程），因此遵循类似agile methodology之类的东西是有意义的（更像是瀑布之类的东西）方法）。换句话说，您需要计划您的分析是迭代和自我反思。
那就是说，我认为统计分析纯粹是探索性而没有目标的概念可能存在问题。这可能导致你超过尤里卡时刻的5步，并且无法回到它。即使目标本身正在改变，总会有某种目标。而且，如果没有目标，你怎么知道什么时候到达终点？
一种方法是在启动项目时启动一个R文件（或者像Josh和Bernd示例中的一组文件），并在发现时逐步添加（以使其增大） 。当您需要将数据保留为分析的一部分时，尤其如此。此文件应定期进行版本控制，以确保在出错时始终可以倒退（允许增量增益）。版本控制系统在开发过程中非常有用，不仅因为它们确保您不会丢失任何东西，还因为它们为您提供了时间轴。并标记您的签到，以便您一目了然地了解其中的内容，并注意主要的里程碑。我喜欢JD关于在提交内容之前办理登机手续的要点。
一旦得出最终结论，通常最好创建一个文件的最终版本，从头到尾总结您的分析。您甚至可以考虑将其放入Sweave文档中，以使其完全自包含且识字。
你还应该认真考虑周围的人在做什么。没有什么能让我更加畏缩，而不是看到人们重新发明轮子，特别是当它意味着整个集团的整体工作需要额外的工作时。
您对使用哪个版本控制系统，哪个IDE等（实施问题）的决定最终在整个项目管理的图腾柱上极低。只需正确地使用任何其中一个，你就已经95％了，并且与使用任何东西的替代方案相比，它们之间的差异很小。
最后，如果您使用的是github，Google代码或R-forge之类的东西，您会注意到它们都有一些共同之处：除了版本控制系统之外的一套工具。也就是说，您应该考虑使用诸如问题跟踪系统和维基之类的内容来记录进度并记录打开的问题/任务。您的分析越有条理，成功的可能性就越大。
答案 2 :(得分：5)
我正在使用git进行版本控制。我的典型目录结构（例如文章）如下。
.
..
.git
README
README.html
ana
dat
doc
org
大多数目录/文件（ana，doc，org）都受版本控制。当然，大型二进制数据集从版本控制中排除（通过.gitignore）。 README是一个Emacs组织模式文件。
答案 3 :(得分：3)
阅读完更新后，您似乎正在查看选择和使用版本控制系统来指示存储库的结构和工作流程。在我看来，版本控制更类似于保险政策，因为它提供以下服务：
备份。如果某些东西被意外删除或命运的突发事件炸毁你的硬盘驱动器，你的工作可以从存储库中恢复。使用分布式版本控制，没有什么能够让你放松工作 - 在这种情况下，你可能还有其他事情需要担心。
所有撤消按钮的母亲。一小时前分析看起来更好吗？一天前？一周前？版本控制提供了一个倒带按钮，可让您及时返回。
如果您是唯一一个从事项目的人，上述两点可能会概述版本控制系统将如何影响您的工作方式。
版本控制系统的另一方面是，它们通过允许人们在项目材料的隔离副本或“分支”上进行实验，然后将任何正面更改“合并”回主副本，从而促进协作。它还为项目成员提供了一种方法，可以密切关注哪些更改会影响哪些文件行。
作为一个例子，我将所有大学课程作为版本控制保存在 Subversion 存储库中。我是唯一一个在这个存储库上工作的人，所以我永远不会分支或合并源 - 我只是提交并偶尔回放。回放工作的能力降低了尝试某种新分析的风险 - 我只是这样做。如果两个小时后它看起来不是一个好主意，我只需还原项目文件并尝试不同的东西。
相比之下，我的大部分非课程包/程序开发都在 git 下托管。在这种设置中，我经常想要在分支上进行实验，同时提供稳定的主副本。在这些情况下，我使用 git 而不是 Subversion ，因为 git 使得分支和合并成为一项轻松的任务。
重要的一点是，在这两种情况下，我的存储库的结构和我使用的工作流程不是由我的版本控制系统决定的 - 它们是由由我。版本控制对我的工作流程的唯一影响是，它让我免于担心尝试新事物，决定我不喜欢它，然后必须撤消所有更改以回到我开始的地方。因为我使用版本控制，所以我可以遵循Yogi Berra的建议：
当你来到路边的叉子时，请把它拿走。
因为我总是可以回去拿另一种方式。
答案 4 :(得分：1)
我自己使用git。本地存储库，存储在与R项目相同的目录中。这样，如果我在路上消除一个项目，那么存储库就会随之而来;我可以离线工作;我没有处理IRB，FERPA，HIPPA问题。
如果我需要添加备份保证，我可以git到远程（安全！）存储库。
-Wil