如果你從沒用過,而有人提及或想導入一套版本控制系統時,你會想些什麼?為什麼我需要用它?沒聽過「版本控制」這名詞之前,也過得好好的?我(或我們)不需要版本控制?

事實真的是如此嗎?會不會在說出不需要版本控制時,其實你已經作過版本管理了?只不過是以一種隨意、不一致、無效率、沒有共識的方式在進行罷了?

你其實做過版本管理

別說你沒用過版本管理,現代的應用程式,絕大多數都有著回復(undo)、重做(redo)的功能,想像一下,偶而地,你會遇到某個應用程式不提供這類功能,那麼,在操作錯誤而想回復上一步,或者是想看看近幾次步驟彼此間的差異時,就會有點抓狂。

如果想試著在既有的成品上加點什麼,為了不破壞目前的作品,你會另存新檔,也許在檔名上再加上v1、v2這類標籤,或者會再更精細一些,加上個時間與日期,這樣就可以在出包的時候,取得某個時間點可用的狀態,看看哪邊出了問題。

手動處理這類瑣事其實沒有效率,如果使用應用程式的人夠多,那麼應用程式也許會將自動備份實作為特色之一,文書處理相關的應用程式特別會考量這類功能,例如Word之類的文書處理程式,通常會提供追蹤校訂的功能,可以檢視文件修改前後的差異,可以加上註解,說明修改的原因等,在多人合作編輯的場合下,也可以標示是誰作出了修改,能接受或拒絕修訂,若修改來自兩份文件,也可比較文件差異或進行合併。

當然,最後的成果可能不只是一個檔案,而是一個或數個目錄下許多資源組成,這麼一來事情就會越來越複雜,若又得多人共同合作編輯,就越需要有些版本上的規範,你可能會公開分享某個目錄,需要編輯的人必須從目錄中取出檔案,編輯完畢後再送回目錄之中,如果同時間有人要編輯同一個檔案或目錄,那又該怎麼辦呢?

你得有些策略,像是鎖定檔案直到上一個人編輯完成送回,下一個才能取出檔案進行編輯之類的,如果在自己的電腦上就有一份版本,那麼可能得隨時同步一下公開目錄中的狀態,每一份檔案修改的時間、註解等,你又會是怎麼管理?

為什麼要做這些動作?因為我們怕搞爛了東西,但又不知道搞爛了什麼!因此,必須有個方式,可以在作品的每個正確時間點上留下一個狀態,這樣才會有比較的基準,當問題發生時,才有辦法用某個可用狀態來追蹤問題所在。

你一定曾為了上述這個目的,而作過類似的版本管理動作,只是每個人對「每一個正確的時間點上留下一個狀態」的解讀與做法方式,並不相同,甚至是自己本身,在每個時期,也可能各有不同、自以為足夠應付需求的版本管理策略。

前進版本控制系統

實際上每個人都做過版本管理,只是方法不同,需求不同,而版本控制系統,基本上就是將這類需求做了統合,實作出可適用於多數場合的工具,這個工具會是獨立於目前製作作品的應用程式外的另一個產品,因而為了使用版本控制系統,你得付出一點時間,改變目前版本管理的做法與習慣,學習額外的名詞、觀念與指令。

對於不擅於應付變化的人來說,這就會是種負擔了,更別說想要不擅於應付變化的團隊來接受、導入一套新的版本控制系統。

實際上,那些版本控制系統中主要的概念並非憑空產生,看看之前提到的各個場景中出現的文字吧!備份、回復、差異、標籤、時間、註解、取出、送回、誰作出了修改、接受或拒絕、合併、同步等,如果你曾接觸過,或者現在去翻閱一下版本控制系統的說明文件,一定可以找到對應這些文字的(英文)名詞或概念。

老實說,這些基本的名詞與概念,並不太需要多做解釋,至少,之前的場景描述或你既有的經驗,已經解釋了大半。

或許會抗拒特別學習一套系統來進行版本控制的原因之一,是你用不了其中所有的功能,這是事實,對大多數個人使用來說,版本控制需求多半只是在唯一的一條時間軸上,做線性移動而已,或許你也只需要學習夠用的功能就可以了(畢竟沒用到的功能也一定會忘了怎麼用)。

而誘因之一則可以是,版本控制系統會比你自創的版本管理,來得有效率。以Git來說,單單只是commit的動作,就可以完成過去你許多手動處理版本的許多步驟。

若是多人合作編輯的場合,那麼,選用一套版本控制系統,絕對是更有效率,畢竟,版本控制系統基本上,就是為了多數人合作編輯而設計,然而,更重要的是,當多人使用同一套版本控制系統時,就能建立起共同的術語,避免以各自的方式來解讀版本的概念,例如說時間的格式好了,如果只是規範修改時必須標記時間,那麼,每個人在標記時間時,可能就會有各自不同的格式了吧!

認識版本控制的各種需求

大凡所有介紹版本控制系統的書籍,都會在一開始列出你為什麼需要版本控制系統,不過,多半使用程式碼專案來加以說明,實際上,就如方才所言,你一定早就做過版本管理之類的動作,只不過是以自己的方式,用在自認為需要的場合,想換用版本控制系統,最好的方式是直接將過去的版本管理做法,改以版本控制系統來處理,像是書籍的作者,可以改用版本控制系統來發布範例原始碼檔案,或者僅僅只是勘誤。

也只有在你開始真正使用一個版本控制需求時,你才會發現,原來版本控制可用的場合與需求,並不只限於過去自我想像的方式,這特別是在你試著從一些文件或書籍中,進一步瞭解版本控制的最佳實踐時會發現。

舉例來說,過去你總以為不需要在某個時間點留下可用狀態或訊息,經常等到需要回復狀態時,才後悔莫及;學習版本控制系統時,則會告訴你commit early and commit often,同時,最好保持每個commit版本修改的功能簡單,且只有一個目的。

個人自行處理版本控制議題時,經常的習慣是僅在單一時間軸上前後線性地移動,實際上,每當在既有可運作的東西上加新的特性時,開個新分支(Branch)會是比較建議的方式。

在新特性完成之後,可以合併回主幹,這會比使用單一時間軸來得有彈性,特別是在只需要有某幾個特性的分支版本時,往往在學習版本控制系統的過程中,才會猛然回憶起,過去某個場景,就是沒有採取目前看到的策略,而徒然耗費許多功夫。

釐清自己的版本控制需求

不過,使用版本控制系統時,最麻煩的還是指令,以及每個指令下可附加的選項,版本控制系統確實沒有辦法避免一堆的指令,因為它們都考量了版本控制需求的多樣性,因此,每本探討版本控制介紹書籍或文件中,列出的指令都很嚇人,不過,根據每個人的需求不同,常用的一定只有那麼幾個,你甚至可以選擇一個最符合目前使用習慣的圖形介面程式作為開始,作為完全習慣新的版本控制系統前的過度工具。

最重要的,還是承認一件事:你(或者是團隊中)一定做過版本控制,只不過也許太隨意了。因而在選擇採取哪套版本控制系統時,重點是擺在這個過程中,能學習與認清自己的版本控制需求,並決定一套經過驗證可行的策略,修正過去漫不經心的版本控制做法,而不是被版本控制系統中那一大堆的名詞、概念與指令給迷惑,而一味地抗拒採取一套真正有效率的版本控制系統。

 

作者簡介


Advertisement

更多 iThome相關內容