背景
什麼是分支?簡單地說,分支就是兩個相對獨立的時間線,正常情況下,獨立的時間線永遠不會有交集,彼此不知道對方的存在,只有特定情況下,兩條時間線才會相遇,因為相遇,所以相知,因為相知,所以改變!
正如分支對於科幻電影來說是一個很好的賣點,關於分支的話題完全可以開啟新的題材,對於這點相信不少科幻迷都深有體會,不必贅述.
迴歸正題,分支對於版本控制系統又意味著什麼呢?實際工作中,我們大多作為一個團隊一起合作開發專案,如果是獨立開發者,只有一個人的話,其實用不到分支的概念,甚至遠端倉庫也用不到.所以下述情況針對的都是團隊開發情況.
作為團隊中的一員不論是專案領導還是專案成員,都需要了解並掌握分支的一般概念和常用操作.如果你剛好是實際開發的程式猿,上級領導分派一個新功能,預期兩個星期內才能完成,其他同事也是如此,每個人都有自己的任務.接收任務就要開始幹活,第一天工作開了一個頭,還留下一大堆的 TODO 標記,此時你照例執行 git add ,git commit 等命令,學會上節的git push origin master 你知道了本地倉庫和遠端倉庫的概念,你想將你的工作成果分享給其他人就要推送到遠端倉庫,這樣其他人才能可見,等一等,別急!
首先明確的是,這個完整功能至少需要2個星期才能基本完成啊,你現在剛剛起了個頭還沒完成呢!你要是真的推送到遠端倉庫了,那其他人是不是有理由認為你這部分功能已完成?那你可能會反駁說,我可以在工作群吼一聲,說這個功能還沒完成,大家彆著急使用哈!這樣確實可以,很長一段時間內其他人必須無視你的程式碼,只有等你的功能基本可用時,等你再吼一聲,別人才會去使用你的程式碼.粗略一看,好像並沒有什麼問題?!
實際上這種情況是存在很大風險的,因為未完成未經過測試的程式碼可能會產生大量意外 bug,嚴重的話,甚至影響整個系統,到時候由於你的未完成程式碼導致別人專案都無法執行,那別人還怎麼工作,這個責任是誰負責?
所以,為了不給其他人造成麻煩,最好不要把未完成工作直接暴露到別人面前,那長時間提交又可能會造成丟失更改的風險,此時此景,平行時間線應用而生!
從接手新功能的時間點開始,建立一條新的時間線,於是新功能的開發完全在新的時間線上進行,至於其他人是否開啟新的時間線那就不是我們能控制得了,我們能做到的就是不給其他人制造麻煩,如果其他人給我們製造麻煩的話,那我們就去上級領導那告他一狀,哈哈!
等功能開發差不多時,你再想辦法切換到原來的時間線上並將開發時間線的更改順便都帶過來,這樣一來,別人雖然看不到你的開發時間線,但是看到了你離開的這段時間原來做了這麼多的更改啊!
現在用git的專業術語再解釋一遍上述場景:
接手新功能的時刻開始,建立一個開發分支(既可以是本地分支也可以是遠端分支),以後新功能的開發全部在開發分支上完成,處於開發分支上你可以照常執行 git add ,git commit 等命令,不用擔心丟失更改.等工作一段時間後,終於完成了新功能,是時候讓新功能展示給其他同事了.此時再切換到原來的主幹分支,在主幹分支上合併開發分支,現在主幹分支上已經有新功能了,這樣一來,其他同事突然發現你已經偷偷地完成了新功能的開發!
不僅 git 有分支概念,其他版本控制系統比如 svn 也有分支概念,基本概念和常用操作類似,只不過 git 更強大,建立分支,切換分支,合併分支等功能十分強大,效率太高!
(svn 建立分支,切換分支等操作簡直慢到可以喝一杯茶了,分支管理都快成擺設了!)
建議
- 開發新功能時儘量建立自己的分支,不要給其他人造成麻煩
- 分配任務時要求專案成員建立各自分支,等時機成熟時再合併到主幹分支