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使分支和合並一個毫不費力的任務。

重要的一點是，在這兩種情況下我的倉庫的結構和工作流程我用的不是我的版本控制決定系統 - 它們是由我決定的。版本控制對我的工作流程的唯一影響是，它使我免於擔心嘗試新事物，決定不喜歡它，然後必須撤消所有更改才能返回到我開始的位置。因爲我使用的版本控制，我可以按照約吉貝拉的建議是：

當你在一個岔路口，把它。

因爲我總是可以回頭，並採取其他方式。