崇拜眼光閃閃閃!事情的原由是這樣，A 客戶說這次改版要新功能，所以就先麻煩後端工程師協助調整，這當中 A 客戶又打來說這次要多加這邊那邊，我只好想辦法在架構不變的情形下看能把新的需求怎麼跟現有的做平衡，不然可能會被打死(?! 誇張了)，孰不知後端工程師手腳很快地推了一個新版本，但我還在跟客戶用前一版如火如荼討論中 XDD
還有一次的情形是，在跟工程師討論那邊的功能實際的條件是哪些，我滿心疑問啥時說要改這樣了，工程師就把版本記錄叫出來指給我看..
工程師：「這個需求吼，是 x 月 x 號接受到的指示，我當天就改了，這需求更改還連動到很多其他功能一起改，你們回去溝通一下。」
我：「
是，我回去問一下。（小步快閃）」
以上的經驗造就今天的文章靈感，做點版本控制的小筆記。
大家好，我是 Jade Chang
先前任職於科技外商，主要負責對於 Developers 的開發經驗體驗，過去 5-6 年出沒於技術社群以及大專院校。嘗試過直播節目、技術黑客松、帶狀節目系列以及線上短期活動等行銷策略，半年前轉職到台灣在地的軟體開發商，從事行銷與專案經理，也合夥新創了一間數位公司，超展開職涯要開始囉!!!
相信大家都有備份的經驗，想要減少資料不見的機率，都會選擇定期將想要留存的資料做備份，有了備份，就有辦法還原，版本控制，顧名思義，就是將文件每一次的更動都做一次的紀錄，過往大家在團隊作業或是甚至個人文件有持續在更新的時候很常會有以下的狀況，最原始的檔案之外，會將每次更新或是階段性討論的結果在原檔案後面加上修改的日期來做區別，還記得大學的報告會有這種檔名出現「最終版」、「 Final 最終版」、「真是最後一版」、「拜託是最終版」。
版本控制的出現除了是記錄每次版本的更動外，更多的是強調更動的地方 像是上面的圖示，看起來每次的版本都有被做紀錄，但是硬要說 0601 跟 0611 中間調整了哪裡是真的蠻難記得的..版本控制另外也是能提供協做專案的人們，可以有機會往前回復到前一次的狀態，這種選擇在軟體開發上又顯得格外重要，如果哪邊改壞了，至少還有回到過去的選項。
(圖片來源: 為你自己學 Git)
對於一個多人共同作業的軟體開發商，一個專案可能會交由 2-3 人各司其職一起開發，如果善於使用版本控制系統的話，可以避免程式碼被別人或自己不小心覆蓋或遺失的問題，也可以紀錄誰因為什麼原因在甚麼時間改了這段程式碼，開發人員只要將每次程式碼的變更都紀錄（Commit）起來，並且透過版本控制系統中進行更新，就能維持專案的資訊透明度以及可回朔性，當然更迭備份儲存的機率要有一定的頻繁以保持萬一損壞要復原的最小損失，備註也要寫的其他人看得懂，在專案的協做與交接上才會更加順利。
最原始的版控系統 VCS（Version Control System），就是像第一段談到的資料定期在做備份，但相對來說就是當今天悲劇發生在本地端，就也還是面臨資料全部不見的問題。
接續上面提到的 VCS，通常資料還會面臨到的狀況是 共用 的需要，一個團隊我們先簡單說只有 2 個人好了，兩人只能用同一台電腦做協做，做完統一儲存，A 用 B 就不能用，解決問題的時間就只能排順序，團隊再大一點就要排很久很久，也導致效率大減。為了方便多人共用，便出現了備份+共用的版控，CVCs（Centralized Version Control System），可以在多台電腦共同使用一個資料，但一樣資料都在本地端，一樣會有本地災難資料就不見得風險存在。
這時候耳熟能詳的 Git 就登場了，與其他版控系統最大的差異就於改為 分散式儲存， DVCs（Distributed Version Control System） 將資料分散儲存於不同設備上，解決了「單一儲存」這項風險，就算一個儲存裝置壞掉，還有其他裝置可以來解救，同時也提供離線處理的優勢，等有網路時會再同步回原專案。
Git = GitHub? GitHub = Git?
Git 是一個版本控制系統的軟體，而 GitHub 是將安裝在電腦上的軟體放到網頁上，將指令類型的操作透過網頁與 UI 的介面方式給大眾使用，GitHub 服務的本質也是採用 Git 的概念，將專案除了作者本機上儲存外也放在 GitHub 網站上做儲存，可以被其他需要這專案的人 Pull (拉) 下來做開發，再 Push (推) 回去，讓專案一直能維持最新的版本，隨時要加入開發的人都能使用到新的版本做延伸。
參考網站 :
歡迎訂閱我 Medium 或是透過 Facebook 一起來交流<3
iThome鐵人賽
看影片追技術