為什么要進行版本控制

版本控制的原因

  上圖是一個CAD設計師的施工圖文件夾，他需要修改原來的施工圖，但是他又不想把修改前的文件狀態和內容給破壞掉，因為如果直接修改，萬一修改的有問題，或者后悔修改了，如果以前的文件狀態還在的話，大不了把修改糟糕了的刪除了就是了，所以他其實就用到了最簡單的版本控制方法，那就是復制重命名；
  具體寫程序的過程也是一樣的道理，其實就是一個反復編輯，不厭其煩的編輯的過程。你修改的時候不希望破壞掉修改前的狀態，最好就是每修改一段事件，能夠保存一個狀態，類似系統的自動快照一樣，當后面出現問題的時候，可以自由選擇復原到之前的某個快照狀態；
  還有一個原因，那就是，最后發布軟件的時候很多時候會有多個版本，而生成軟件的源代碼卻往往只有一份，只是在最后編譯生成的時候用到不同的部分，大部分代碼還是共用的，所以往往需要版本控制，幾個版本復制幾個文件夾出來；
  版本控制的過程也是過程追蹤記錄，成就達成的過程。
  還有就是很多時候做一個項目，往往不是單槍匹馬單打獨斗的，是需要很多個人之間合作的，多人合作自然也需要進行多份文檔可以編輯，最后再來合並；
  當然，上面主要是說明版本控制的方法並不是現在軟件行業的版本控制方法，因為缺點很多：

• 首先，需要手工操作復制，慢，繁瑣，而且大部分時候我們改動的只是很小的一部分，但每次都要把整個文件夾復制一份出來，這個自然是不合適的。
• 其次，多份快照之間到底有什么不同，這個怎么知道？靠記憶顯然扯淡，每個快照附一份說明區別的文件顯然也太扯淡了。
• 最后，多個備份的硬盤占用問題；

版本控制的方式

  鑒於上面的原因，於是就出現了很多版本控制的工具，這些工具能夠做到隨時提交快照，並附帶上一個小的log說明這次更改的內容；而且控制方式是采用增量的方式，所以項目體積不會占用太多；如果你想知道前后有什么區別，這些工具還能給你提供基於文本對比，給你展示哪些地方進行過修改；如果編輯出問題，可以隨時會到之前提交過的任一快照。多人合作，權限控制，多個分支等等，Good and Strong.

集中式版本控制

  集中式顧名思義就是代碼集中到服務器，用的時候每個人把自己需要的被授權的那部分代碼下載到自己的計算機上，提交也是最后提交到服務器上，服務器可以對代碼做很好的控制，但是需要有網絡，網絡斷了，就沒法工作了。
  代表就是SVN,Team Foundation等

分布式版本控制

  分布式自然就是每個人的地方多有一份完全的代碼，提交和管理都是在本地進行，雖然有遠端倉庫，不過那是最終提交用的，沒聯網本地也是完整代碼的，只是每次需要最新的代碼的時候才必須聯網；分布式的代表就是git，對應的網上倉庫比較有名的就是github.

版本控制的問題

  主要是多個人合作的時候，可能會發生兩個人同時提交一個文件的不同更改，這時候版本控制上就會出現沖突，就必須人工介入來決定保留誰的，否決誰的，當然這個事情是由倉庫的建立者決定的。
  目前的版本控制對文本內容有很好的支持，但是對二進制文件幾乎沒有支持，所以盡量不要在二進制文件上用這些版本控制工具，這不是他們的長處，二進制文件還是老老實實復制重命名吧，所以說其他設計行業的人苦逼啊。