如果你從沒用過，而有人提及或想導入一套版本控制系統時，你會想些什麼？為什麼我需要用它？沒聽過「版本控制」這名詞之前，也過得好好的？我（或我們）不需要版本控制？
事實真的是如此嗎？會不會在說出不需要版本控制時，其實你已經作過版本管理了？只不過是以一種隨意、不一致、無效率、沒有共識的方式在進行罷了？
你其實做過版本管理
別說你沒用過版本管理，現代的應用程式，絕大多數都有著回復（undo）、重做（redo）的功能，想像一下，偶而地，你會遇到某個應用程式不提供這類功能，那麼，在操作錯誤而想回復上一步，或者是想看看近幾次步驟彼此間的差異時，就會有點抓狂。
如果想試著在既有的成品上加點什麼，為了不破壞目前的作品，你會另存新檔，也許在檔名上再加上v1、v2這類標籤，或者會再更精細一些，加上個時間與日期，這樣就可以在出包的時候，取得某個時間點可用的狀態，看看哪邊出了問題。
手動處理這類瑣事其實沒有效率，如果使用應用程式的人夠多，那麼應用程式也許會將自動備份實作為特色之一，文書處理相關的應用程式特別會考量這類功能，例如Word之類的文書處理程式，通常會提供追蹤校訂的功能，可以檢視文件修改前後的差異，可以加上註解，說明修改的原因等，在多人合作編輯的場合下，也可以標示是誰作出了修改，能接受或拒絕修訂，若修改來自兩份文件，也可比較文件差異或進行合併。
當然，最後的成果可能不只是一個檔案，而是一個或數個目錄下許多資源組成，這麼一來事情就會越來越複雜，若又得多人共同合作編輯，就越需要有些版本上的規範，你可能會公開分享某個目錄，需要編輯的人必須從目錄中取出檔案，編輯完畢後再送回目錄之中，如果同時間有人要編輯同一個檔案或目錄，那又該怎麼辦呢？
你得有些策略，像是鎖定檔案直到上一個人編輯完成送回，下一個才能取出檔案進行編輯之類的，如果在自己的電腦上就有一份版本，那麼可能得隨時同步一下公開目錄中的狀態，每一份檔案修改的時間、註解等，你又會是怎麼管理？
為什麼要做這些動作？因為我們怕搞爛了東西，但又不知道搞爛了什麼！因此，必須有個方式，可以在作品的每個正確時間點上留下一個狀態，這樣才會有比較的基準，當問題發生時，才有辦法用某個可用狀態來追蹤問題所在。
你一定曾為了上述這個目的，而作過類似的版本管理動作，只是每個人對「每一個正確的時間點上留下一個狀態」的解讀與做法方式，並不相同，甚至是自己本身，在每個時期，也可能各有不同、自以為足夠應付需求的版本管理策略。
前進版本控制系統
實際上每個人都做過版本管理，只是方法不同，需求不同，而版本控制系統，基本上就是將這類需求做了統合，實作出可適用於多數場合的工具，這個工具會是獨立於目前製作作品的應用程式外的另一個產品，因而為了使用版本控制系統，你得付出一點時間，改變目前版本管理的做法與習慣，學習額外的名詞、觀念與指令。
對於不擅於應付變化的人來說，這就會是種負擔了，更別說想要不擅於應付變化的團隊來接受、導入一套新的版本控制系統。
實際上，那些版本控制系統中主要的概念並非憑空產生，看看之前提到的各個場景中出現的文字吧！備份、回復、差異、標籤、時間、註解、取出、送回、誰作出了修改、接受或拒絕、合併、同步等，如果你曾接觸過，或者現在去翻閱一下版本控制系統的說明文件，一定可以找到對應這些文字的（英文）名詞或概念。
老實說，這些基本的名詞與概念，並不太需要多做解釋，至少，之前的場景描述或你既有的經驗，已經解釋了大半。
或許會抗拒特別學習一套系統來進行版本控制的原因之一，是你用不了其中所有的功能，這是事實，對大多數個人使用來說，版本控制需求多半只是在唯一的一條時間軸上，做線性移動而已，或許你也只需要學習夠用的功能就可以了（畢竟沒用到的功能也一定會忘了怎麼用）。
而誘因之一則可以是，版本控制系統會比你自創的版本管理，來得有效率。以Git來說，單單只是commit的動作，就可以完成過去你許多手動處理版本的許多步驟。
若是多人合作編輯的場合，那麼，選用一套版本控制系統，絕對是更有效率，畢竟，版本控制系統基本上，就是為了多數人合作編輯而設計，然而，更重要的是，當多人使用同一套版本控制系統時，就能建立起共同的術語，避免以各自的方式來解讀版本的概念，例如說時間的格式好了，如果只是規範修改時必須標記時間，那麼，每個人在標記時間時，可能就會有各自不同的格式了吧！
認識版本控制的各種需求
大凡所有介紹版本控制系統的書籍，都會在一開始列出你為什麼需要版本控制系統，不過，多半使用程式碼專案來加以說明，實際上，就如方才所言，你一定早就做過版本管理之類的動作，只不過是以自己的方式，用在自認為需要的場合，想換用版本控制系統，最好的方式是直接將過去的版本管理做法，改以版本控制系統來處理，像是書籍的作者，可以改用版本控制系統來發布範例原始碼檔案，或者僅僅只是勘誤。
也只有在你開始真正使用一個版本控制需求時，你才會發現，原來版本控制可用的場合與需求，並不只限於過去自我想像的方式，這特別是在你試著從一些文件或書籍中，進一步瞭解版本控制的最佳實踐時會發現。
舉例來說，過去你總以為不需要在某個時間點留下可用狀態或訊息，經常等到需要回復狀態時，才後悔莫及；學習版本控制系統時，則會告訴你commit early and commit often，同時，最好保持每個commit版本修改的功能簡單，且只有一個目的。
個人自行處理版本控制議題時，經常的習慣是僅在單一時間軸上前後線性地移動，實際上，每當在既有可運作的東西上加新的特性時，開個新分支（Branch）會是比較建議的方式。
在新特性完成之後，可以合併回主幹，這會比使用單一時間軸來得有彈性，特別是在只需要有某幾個特性的分支版本時，往往在學習版本控制系統的過程中，才會猛然回憶起，過去某個場景，就是沒有採取目前看到的策略，而徒然耗費許多功夫。
釐清自己的版本控制需求
不過，使用版本控制系統時，最麻煩的還是指令，以及每個指令下可附加的選項，版本控制系統確實沒有辦法避免一堆的指令，因為它們都考量了版本控制需求的多樣性，因此，每本探討版本控制介紹書籍或文件中，列出的指令都很嚇人，不過，根據每個人的需求不同，常用的一定只有那麼幾個，你甚至可以選擇一個最符合目前使用習慣的圖形介面程式作為開始，作為完全習慣新的版本控制系統前的過度工具。
最重要的，還是承認一件事：你（或者是團隊中）一定做過版本控制，只不過也許太隨意了。因而在選擇採取哪套版本控制系統時，重點是擺在這個過程中，能學習與認清自己的版本控制需求，並決定一套經過驗證可行的策略，修正過去漫不經心的版本控制做法，而不是被版本控制系統中那一大堆的名詞、概念與指令給迷惑，而一味地抗拒採取一套真正有效率的版本控制系統。