git 入門教程之分支管理

時間 2019-11-15

標籤 git 入門教程分支管理欄目 Git 简体版

原文原文鏈接

背景

什麼是分支?簡單地說,分支就是兩個相對獨立的時間線,正常狀況下,獨立的時間線永遠不會有交集,彼此不知道對方的存在,只有特定狀況下,兩條時間線纔會相遇,由於相遇,因此相知,由於相知,因此改變!git

正如分支對於科幻電影來講是一個很好的賣點,關於分支的話題徹底能夠開啓新的題材,對於這點相信很多科幻迷都深有體會,沒必要贅述.svn

迴歸正題,分支對於版本控制系統又意味着什麼呢?實際工做中,咱們大多做爲一個團隊一塊兒合做開發項目,若是是獨立開發者,只有一我的的話,其實用不到分支的概念,甚至遠程倉庫也用不到.因此下述狀況針對的都是團隊開發狀況.測試

做爲團隊中的一員不管是項目領導仍是項目成員,都須要瞭解並掌握分支的通常概念和經常使用操做.若是你恰好是實際開發的程序猿,上級領導分派一個新功能,預期兩個星期內才能完成,其餘同事也是如此,每一個人都有本身的任務.接收任務就要開始幹活,第一天工做開了一個頭,還留下一大堆的 TODO 標記,此時你照例運行 git add ,git commit 等命令,學會上節的git push origin master 你知道了本地倉庫和遠程倉庫的概念,你想將你的工做成果分享給其餘人就要推送到遠程倉庫,這樣其餘人才能可見,等一等,別急!版本控制

首先明確的是,這個完整功能至少須要2個星期才能基本完成啊,你如今剛剛起了個頭還沒完成呢!你要是真的推送到遠程倉庫了,那其餘人是否是有理由認爲你這部分功能已完成?那你可能會反駁說,我能夠在工做羣吼一聲,說這個功能還沒完成,你們彆着急使用哈!這樣確實能夠,很長一段時間內其餘人必須無視你的代碼,只有等你的功能基本可用時,等你再吼一聲,別人纔會去使用你的代碼.粗略一看,好像並無什麼問題?!code

實際上這種狀況是存在很大風險的,由於未完成未通過測試的代碼可能會產生大量意外 bug,嚴重的話,甚至影響整個系統,到時候因爲你的未完成代碼致使別人項目都沒法運行,那別人還怎麼工做,這個責任是誰負責?開發

因此,爲了避免給其餘人形成麻煩,最好不要把未完成工做直接暴露到別人面前,那長時間提交又可能會形成丟失更改的風險,此時此景,平行時間線應用而生!it

從接手新功能的時間點開始,建立一條新的時間線,因而新功能的開發徹底在新的時間線上進行,至於其餘人是否開啓新的時間線那就不是咱們能控制得了,咱們能作到的就是不給其餘人制造麻煩,若是其餘人給咱們製造麻煩的話,那咱們就去上級領導那告他一狀,哈哈!ast

等功能開發差很少時,你再想辦法切換到原來的時間線上並將開發時間線的更改順便都帶過來,這樣一來,別人雖然看不到你的開發時間線,可是看到了你離開的這段時間原來作了這麼多的更改啊!效率

如今用git的專業術語再解釋一遍上述場景:bug

接手新功能的時刻開始,建立一個開發分支(既能夠是本地分支也能夠是遠程分支),之後新功能的開發所有在開發分支上完成,處於開發分支上你能夠照常運行 git add ,git commit 等命令,不用擔憂丟失更改.等工做一段時間後,終於完成了新功能,是時候讓新功能展現給其餘同事了.此時再切換到原來的主幹分支,在主幹分支上合併開發分支,如今主幹分支上已經有新功能了,這樣一來,其餘同事忽然發現你已經偷偷地完成了新功能的開發!

不只 git 有分支概念,其餘版本控制系統好比 svn 也有分支概念,基本概念和經常使用操做相似,只不過 git 更強大,建立分支,切換分支,合併分支等功能十分強大,效率過高!
(svn 建立分支,切換分支等操做簡直慢到能夠喝一杯茶了,分支管理都快成擺設了!)