一、我們采用的管理策略（分支開發(fā)主干發(fā)布） 1. 主分支（master），用于發(fā)布，每次發(fā)布時(shí)打一個(gè)（tag），不做任何開發(fā)使用 拉取源：無 合并目標(biāo)：無 修改：不允許 生命周期：持續(xù) 2. 開發(fā)分支（develop），每次有新需求時(shí)，從（master）拉取創(chuàng)建一個(gè)新分支，測試完成后合并到（master），合并后需要重新測試 拉取源：master 合并目標(biāo)：master 修改：允許 生命周期：合并后刪除（上線穩(wěn)定運(yùn)行后再刪除） 3. 測試/預(yù)發(fā)布分支（release），開發(fā)到某一階段時(shí)，創(chuàng)建一個(gè)（release）分支提供測試，如果測試期間，對應(yīng)的開發(fā)分支（develop）有修改，則需要同步到（release）分支，或者直接使用開發(fā)分支（develop）覆蓋（release）分支 拉取源：develop 合并目標(biāo)：無 修改：不允許 生命周期：測試完成后刪除 4. 問題修改分支（hotfix），用于修復(fù)線上問題，從對應(yīng)線上版本的（tag）拉取，修改并測試完成后（merge）到（master），在（master）測試完成后，從（master）發(fā)布，同時(shí)打一個(gè)新的（tag） 拉取源：tag 合并目標(biāo)：master 修改：允許 生命周期：測試完成后刪除（上線穩(wěn)定運(yùn)行后再刪除） 二、GIT操作規(guī)范 1. 代碼修改前，必須先從對應(yīng)分支PULL最新代碼 2. 完成代碼編寫后，COMMIT到本地倉庫，建議經(jīng)常COMMIT到本地倉庫，以防丟失或者被覆蓋 3. PULL最新代碼，如果需要MERGE，原則上不允許覆蓋別人提交的代碼，如果存在沖突的情況，如果不能百分百確定可以覆蓋，需要與相關(guān)開發(fā)人員共同MERGE 4. PUSH本地代碼到遠(yuǎn)程倉庫 5. 代碼開發(fā)階段，不建議頻繁PUSH，如果是公共代碼或者被依賴的代碼，完成測試后即可PUSH 6. 對于多人同時(shí)開發(fā)相同文件，如果存在開發(fā)中但是必須提交的情況，可以先REVERT，修改后COMMIT，然后再從LOCAL HISTORY中將被還原的代碼拉取出來 三、兩種主流的管理策略 1. 主干開發(fā)分支發(fā)布 得到一個(gè)穩(wěn)定版本后，將此穩(wěn)定版本放到一個(gè)新分支上，針對此穩(wěn)定版本的修修補(bǔ)補(bǔ)就在這個(gè)分支上進(jìn)行，新功能不在此分支上開發(fā)，而在主干上進(jìn)行新功能的開發(fā)。 這是業(yè)界采用較多的模式。 穩(wěn)定分支上的有些修改，比如缺陷修復(fù)，需要合并到主干， 但有些特定修改，是不需要合并到主干的。這時(shí)需要千萬注意，合并準(zhǔn)確的文件到主干。 對于不能合并到主干的情況，常見的是再拉一個(gè)分支，這個(gè)分支專門為少數(shù)特定情況而用，但從全局講，可能會導(dǎo)致太多分支，不同分支間混亂，所以這并不推薦。推薦寧愿采用配置開關(guān)。 比如freebsd的發(fā)布就是一個(gè)典型的例子。 freebsd的主干永遠(yuǎn)是current，也就是包括所有最新特性的不穩(wěn)定版本。然后隨著新特性的逐步穩(wěn)定，達(dá)到一個(gè)發(fā)布的里程碑以后，從主干分出來一個(gè)stable分支。freebsd是每個(gè)大版本一個(gè)分支。也就是說4.x，5.x，6,x各一個(gè)分支。每個(gè)發(fā)布分支上只有bug修改和現(xiàn)有功能的完善，而不會再增加新特性。新特性會繼續(xù)在主干上開發(fā)。當(dāng)穩(wěn)定分支上發(fā)生的修改積累到一定程度以后，就會有一次發(fā)布。發(fā)布的時(shí)候會在穩(wěn)定分支上再分出來一個(gè) release分支。以6.x為例，就會有6.0,6.1,6.2…等發(fā)布分支。【此段摘自于網(wǎng)絡(luò) http://thinkernel.bokee.com/4518935.html 】 2. 分支開發(fā)主干發(fā)布 得到一個(gè)穩(wěn)定版本后，拉出先鋒分支，在分支上開發(fā)新功能，在主干上進(jìn)行修修補(bǔ)補(bǔ)。當(dāng)先鋒分支通過一定的測試之后，合并到主干。可以同時(shí)有多個(gè)先鋒分支，不同的功能可以拉不同的分支，不同發(fā)布時(shí)間點(diǎn)而又要同時(shí)開發(fā)的內(nèi)容必須在不同的分支上。 從發(fā)布的角度講，更推薦將肯定一起發(fā)布的內(nèi)容放在相同的先鋒分支上。 主干上永遠(yuǎn)是穩(wěn)定版本，可以隨時(shí)發(fā)布。bug的修改和新功能的增加，全部在分支上進(jìn)行。而且每個(gè)bug和新功能都有不同的開發(fā)分支，完全分離。而對主干上的每一次發(fā)布都做一個(gè)標(biāo)簽而不是分支。分支上的開發(fā)和測試完畢以后才合并到主干。 這種發(fā)布方法的好處是每次發(fā)布的內(nèi)容調(diào)整起來比較容易。如果某個(gè)新功能或者bug在下一次發(fā)布之前無法完成，就不可能合并到主干，也就不會影響其他變更的發(fā)布。另外，每個(gè)分支的生命期比較短，唯一長期存在的就是主干，這樣每次合并的風(fēng)險(xiǎn)很小。每次發(fā)布之前，只要比較主干上的最新版本和上一次發(fā)布的版本就能夠知道這次發(fā)布的文件范圍了。 【此段摘自于網(wǎng)絡(luò) http://thinkernel.bokee.com/4518935.html 】 四、A successful Git branching model 簡單描述： 1.存在一條主分支（master）。所有用戶可見的正式版本，都從master發(fā)布。主分支作為穩(wěn)定的唯一代碼庫，不做任何開發(fā)使用。 拉取源：無需。 合并目標(biāo)：無需。 修改：不允許。 生命期：持續(xù)。 2.存在一條開發(fā)分支（develop）。這個(gè)分支維護(hù)了當(dāng)前開發(fā)中代碼的主線，始終保持代碼新于master。持續(xù)集成、最新隔夜版本的生成等都是基于這個(gè)分支。由于當(dāng)前版本迭代較快，開發(fā)分支只提供拉取，不進(jìn)行實(shí)際開發(fā)。 拉取源：master。 合并目標(biāo)：無需。 修改：不允許。 生命期：持續(xù)。 3.臨時(shí)性多個(gè)功能分支（feature）。從develop拉取。開發(fā)feature完成，merge回develop。為了降低對其他feature的影響，一般在提測前merge回develop分支。 拉取源：develop。 合并目標(biāo)：develop。 修改：允許。 生命期：合并后刪除。 4.臨時(shí)性多個(gè)預(yù)發(fā)布（測試）分支（release），用于QA測試。從develop拉取，測試完成merge回master和develop。如果測試期間，有其他版本合并入master，需要同步到release版本，并進(jìn)行測試。 拉取源：develop。 合并目標(biāo)：master & develop。 修改：允許。 生命期：合并后刪除。 5. 臨時(shí)性多個(gè)bug修復(fù)分支（fixbug），用于修復(fù)線上問題。從master拉取，修復(fù)并測試完成merge回master和develop。如果修復(fù)期間，有其他版本合并入master ，需要同步到fixbug版本，并進(jìn)行測試。 拉取源：master。 合并目標(biāo)：master，develop。 修改：允許。 生命期：合并后刪除。 參考資料： https://nvie.com/posts/a-successful-git-branching-model/ http://www.ituring.com.cn/article/56870 https://www.cnblogs.com/charlesblc/p/6051569.html

轉(zhuǎn)載于:https://www.cnblogs.com/weijs/p/9950395.html

總結(jié)

以上是生活随笔為你收集整理的（GIT）代码分支管理策略的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。