如果你和我一樣：
- 是初學的Blog Programmer
- 有持續修改小程式（如：Blog Template XML檔）的需要
- 習慣使用Gmail
只要你符合以上的條件，那我會建議你看這篇文章。因為，看完這篇文章將有助於你作好個人程式的版本控制。
什麼是軟體「版本控制」？
在Wiki內有針對版本控制的介紹，但我們在這僅介紹軟體的版本控制：
軟體設計師常會利用版本控制來追蹤、維護源碼、文件以及設定檔等等的更動，並且提供控制這些更動控制權的程序。
有時候，一個程式同時存有兩個以上的版本也有其必要性，例如：在一個為了部署的版本中程式錯誤已經被修正、但沒有加入新功能；在另一個開發版本則有新的功能正在開發、也有新的錯誤待解決，這使得同時間需要不同的版本並修改。
此外，為了找出只存在於某一特定版本中（為了修正了某些問題、或新加功能所導致）的程式錯誤、或找出程式錯誤出現的版本，軟體除錯者也必須藉由比對不同版本的程式碼以找出問題的位置。
從上述的敘述中，我們可以歸納出使用版本控制管理程式碼的最主要優點：
- 允許多人協作開發、
- 允許多種版本同時存在、
- 了解各個版本彼此之間的差異。
為什麼我需要「版本控制」來管理程式碼？
從上文看來對單人維護的Blog而言，你或許不需要「同時有多人協作開發」，但你仍會需要版本控制管理程式碼的其他優點：允許多種版本同時存在、了解各個版本彼此之間的差異。
假設，你每次對Blog作的修正都是對的，但如果你永遠只保留一個版本，那你就無法回復到以前的版本。這是「允許多種版本同時存在」的優點。
更何況，你不能保證每次對Blog作的修正都是對的，有時候你根本可能忘記了曾經作過的這些修正、或只是要試一下這次的修正結果如何，因為你沒有保留過去任一版本的檔案，所以你也無從比對新舊版本之間的差異與變化，藉以找出可能修改錯誤的地方。這是「了解各個版本彼此之間的差異」的優點。
儲存證據
是另一個需要版本控制的原因。
網路上喜歡亂貼別人文章的人太多了，所以我每發一篇文章，就會相對應地在 Gmail 內貼上一個文章的文字檔寄給自己，這樣未來如果上了法庭，我就可以主張這篇文章的著作權。
換句話說，亂貼我文章的人請小心了，我是少數有能力提出文章所有人的證據的人。我只是不想提出告訴，但不是提不出證據。
以修改 CSS 為例
Firefox 和 IE 的不同版本，各支援不同的 CSS Filter，例如：Firefox 的3.0.10 版只支援 CSS 2.1，但Firefox的測試版 3.5 Beta4 卻能支援到 CSS 3.0，所以有某些的功能是只能在 3.5 Beta4 上才能看到的；另外，即使是相同的CSS版本，Firefox 和 IE的解釋也不同。
換句話說，即使你的CSS正確，到了不同的瀏覽器中卻很有可能看到不同的樣子。為此，你可能得來回修正多次後，才能決定最後的版本。
以我的經驗為例
為了寫「加速你的Blog」系列的文章，我在文章內所提出的任何一個方法，都是經過自己實際測試的過程。為了測試這些修正，我必須重覆修正程式、上傳程式的動作，以確認這些方法都是有效的。
我之所以能在修改錯了之後，能立即回復到最後一個能正常運作的版本，甚至能比對這次（改壞的）版本與上個正常版本之間的差異，就在於我保留了過去的所有版本。但其實都得歸功於Gmail的特殊功能：「會話群組檢視（Conversation View）」
新的信件呈現方式─「會話群組檢視（Conversation View）」：一來一往間（寄出、回覆、轉寄）的相關信件、相同主題的信件會被群組成同一個「Conversation」，於同一個頁面依時間順序展示，便於相互關照。
善用這個功能，就能把相同主題的信件全歸到一個群組中，再加上每封信的內容都不可以再變更，這個特性幾乎就是版本控制軟體的雛型。
要如何使用 Gmail 作版本控制？
方法其實很簡單。在第一個版本，你只要寫一封信給自己：
- 「主旨」是「軟體的名稱」（你可以想像成專案名稱）如：XXXX；
- 「內文」可以寫「這是XXXX的第一個版本」
- 「附件」上傳這個版本的的檔案
- 「內文」可以寫XXXX在這個最新版本所作的變動/修正
- 「附件」上傳這個檔案的最新版本
另外，我建議還可以在程式內，也加入相對應的記註，如
- 在CSS內加入/* 記註內容 */ ，或是
- 在JavaScript內每行尾// 記註內容
更嚴謹的作法
你得在「內容」填入「發佈（版本）通知(Release Notes)」的內容，但我以「個人觀點」的使用經驗來看，我會建議你至少也得條列出：
- 新版功能(What's New in XXX)
- 已修正的問題(Bug Fixed)
- 已知問題(Known Issues)
這樣你寫的內容，未來才具有參考的價值，尤其是在過了好幾個月之後你還能記得過去的修正記錄。
使用Gmail作版本控制的缺點？
正如wiki 版本控制所言：
軟體設計師可以自己保留一個程式的許多不同版本，並且為它們做適當的編號。這種簡單的方法已被用在很多大型的軟體專案中。這是一個可以達到目的的方法，但不夠有效率。除了得同時維護很多幾乎一樣的程式碼備份外；而且這下子，你知道最需要改變的其實是自己的習慣。極度依賴軟體設計師的自我修養與開發紀律，但這卻常是導致錯誤發生的原因。
但我保證，一旦你熟悉了版本控制的方式，並享受過這個方式所帶來的便利後，你會對版本控制愛不釋手的。
另外，Gmail的單一檔案上限是25Mb，但對一般的個人使用者而言，這個容量應該已經足夠了。
但我還是要提醒大家，如果你很介意Gmail會不會把你的資料搞丟，那你還是把它放到自己的電腦內，但我個人認為就發生中毒、當機、硬碟故障的機率而言，放在Gmail內遠比放在你的電腦內安全。
Q&A
- Q：不一定要用Gmail，任何一種信箱(hotmail、Yahoo! mail、甚至公司的mail)皆可，只要每封信的主旨固定為軟體名稱加版本，然後按照主旨排序就好了。
A: 使用其他的Mail當然也可以，只是少了「會話群組檢視（Conversation View）」功能的信件，會讓你到了進到四、五十版之後，看得頭暈眼花。從上面的圖來看，你真的會頭暈眼花。 - Q：即然都想做版本控制了，為什麼不把完整的機制建立起來，竟然還用這麼爛的方式？
A：有人說「何必為了喝牛奶養一頭牛？」是的！為了文章開頭所說的少量修正需求，就大費周張地架了一個SVN、CVS Service，就我來看未免小題大作。而且Gmail是免費的，到那連線都可以用。以這個角度來看，絕對會比我自己架個Server，又得處理連線、防火牆、...之類的鎖事來得省事。 - Q：這文章是有點牽強，雖然也算是一種版本控管，但是不夠嚴謹。
A：你如果當過填格子、賣字的作家，你就會知道光是要想出一個夠吸引讀者的題裁，就是很不容易的事了。另外，我的需求是只要我能找到之前儲存的版本就夠了，至於要更嚴謹？我想就我的使用需求、和我要付出的代價相比，我真的不覺得有那個必要。
沒有留言:
張貼留言