編者按：機器學習科學家分享了使用git管理數(shù)據(jù)科學試驗的經(jīng)驗。

引言

版本控制是管理數(shù)據(jù)科學試驗的關(guān)鍵工具。但是，魔鬼在細節(jié)之中。這篇文章將討論如何在數(shù)據(jù)科學項目中實現(xiàn)版本控制。

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

策略

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

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

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

例子

我推薦如下的目錄結(jié)構(gòu)：

|-- 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目錄下。試驗以目錄的形式組織，其中包含為試驗執(zhí)行核心邏輯的代碼，以及相應(yīng)的輸入、輸出文件。實現(xiàn)代碼應(yīng)該極為簡單，只做具體試驗特定的事情。例如，如果試驗是要比較A方法和B方法，那么它會引入A和B的配置，從核心實例化相關(guān)代碼，并調(diào)用每個示例的run方法。

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

竅門

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

.gitignore

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

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

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

頻繁提交

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

明晰的提交信息

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

反饋

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