編者按：機器學習科學家分享了使用git管理數據科學試驗的經驗。

引言

版本控制是管理數據科學試驗的關鍵工具。但是，魔鬼在細節之中。這篇文章將討論如何在數據科學項目中實現版本控制。

git的使用有好幾種范式，就數據科學試驗而言，我基本上根據的是特性分支這一范式。簡單來說，特性分支意味著有一個master分支（主分支）作為基礎，新特性通過在主分支上分支的方式加入代碼基，做出實現特性需要的所有改動后，合并新分支至主分支。

策略

我為每個試驗或者想要嘗試的新建模思路創建一個新分支。這時你需要有意識地決策：代碼的修改只適用于這次試驗，還是希望在這次試驗和之前的試驗上都適用？換一種表述方式：你是打算替換，還是增益？這個問題的答案將決定你是否可以把新分支合并回主分支。

我建議額外花一點功夫，將關鍵組件提取出來，作為一個庫，在多次試驗中復用。這比有許多份相同（或者更糟，略有不同）的代碼要好很多，不用分別維護，也不易導致錯誤。俗話說得好，最好的代碼是沒有代碼。將關鍵組件提取至一個共享庫，你可以逐漸做出改進，并最終得到一個內聚的代碼基，可以在一系列試驗復用。相反，如果你不斷引入不向后兼容的改動，你會發現自己頻繁地在分支間跳轉，以便復制/粘貼有用的代碼片段，接著卻需要加以修改，因為組件沒有設計成能夠一起工作的。在較大的試驗中，這會變得很難操作。

特性分支這一方法的優勢在于你可以將試驗分支合并回主分支，接著運行任何試驗。這么做的代價是，當你對核心庫進行改動時，你也許需要同時修改其他試驗的實現。所以，和所有事情一樣，這是一個需要做出權衡的決策。在我的經驗中，這個方法能夠自然地演化，我發現，每當我想要復制粘貼的時候，都會想一下能否提取公共代碼。

例子

我推薦如下的目錄結構：

|-- core/

|-- tests/

|-- test_pull_data.py

|-- test_prepare_data.py

|-- test_model.py

|-- test_deploy.py

|-- test_utils.py

|-- pull_data.py

|-- prepare_data.py

|-- model.py

|-- deploy.py

|-- utils.py

|-- experiment_1/

|-- data/

|-- training.csv

|-- validation.csv

|-- test.csv

|-- output/

|-- results.json

|-- models/

|-- model1

|-- model2

|-- job_config.py

|-- build_data.py

|-- train.py

|-- evaluate.py

|-- prod.py

|-- experiment_2/

|-- data/

|-- training.csv

|-- validation.csv

|-- test.csv

|-- output/

|-- results.json

|-- models/

|-- model1

|-- model2

|-- job_config.py

|-- build_data.py

|-- train.py

|-- evaluate.py

|-- prod.py

在這一情形中，主要邏輯位于core目錄下。試驗以目錄的形式組織，其中包含為試驗執行核心邏輯的代碼，以及相應的輸入、輸出文件。實現代碼應該極為簡單，只做具體試驗特定的事情。例如，如果試驗是要比較A方法和B方法，那么它會引入A和B的配置，從核心實例化相關代碼，并調用每個示例的run方法。

注意這個結構很自然地提供了實現單元/功能/集成測試的地方。此外，單是提取通用組件至可復用的庫這一行動就有助于使代碼更容易測試。由于代碼傾向于基于參數，而非依賴硬編碼的試驗細節，為測試創建玩具樣本就要容易很多。以后我會寫一篇文章，深入討論如何為數據科學項目寫測試。

竅門

下面是一些我覺得在實踐中比較有用的簡單竅門。

.gitignore

.gitignore告訴git忽略哪些文件。在開始一個新項目時，應該優先配置.gitignore。因為一旦你提交了蠢物，它就會永遠呆在代碼倉庫之中（除非你采取了一些特殊行動）。

最重要的是除外敏感信息，比如密碼和API密鑰。如果你早早地提交了包含敏感信息的文件，那么它很快就會變成一場噩夢。從當前快照刪除文件無濟于事——你需要從所有之前的提交中清除敏感信息。對自己好一點，避免去學如何做到這一點。

下一步是忽略非常大的數據文件和你不需要追蹤的不重要文件（例如，notebook檢查點，IDE的配置文件，pycache，.pyc，等等）。在上面的例子中，所有輸入輸出文件也應該忽略，因為它們完全可以由代碼本身確定，如果需要，可以重新生成。

頻繁提交

如果你完成了合理數量的工作，提交一次。不要吝嗇，頻繁提交也許能幫助你避免堵塞。

明晰的提交信息

如果你提交得足夠頻繁，那么你的工作大概也會相當集中，這樣提交信息可以寫得更清晰。回溯不想要的改動時，再沒有比根據恰當注解的提交歷史快速找到目標更令人滿足的了。如果你找到的描述是這樣的：“實現了3個新特性，增加了dropout，創建了交叉驗證組件，同時重構了訓練邏輯”，那么你提交得不夠頻繁。

反饋

我在嘗試不同策略的過程中逐漸積累了這些想法。如果你有不同的做法，歡迎留言分享！