項目開發(fā)流程系列
- 項目開發(fā)混淆從初識到理解
- 項目開發(fā)代碼分支管理
博客創(chuàng)建時間：2022.08.27
博客更新時間：2022.08.28
以Android studio build=7.0.0，SDKVersion 31來分析講解。如圖文和網(wǎng)上其他資料不一致，可能是別的資料版本較低而已。
前言
在團隊開發(fā)中，當(dāng)有多個需求版本進行并發(fā)并行時，選用合適自己的分支管理策略將變得更加必要和急迫，我們來一起認識分支管理的git_flow和github-flow工作流吧。
版本發(fā)布類型
在進行分支管理時不得不科普一下主干發(fā)布 和 分支發(fā)布
主干發(fā)布
的特點就是項目的功能開發(fā)工作在master分支上，代碼開發(fā)完畢后，經(jīng)過功能測試沒有問題后，在master主分支上打release標(biāo)簽作為項目代碼版本進行發(fā)布。是效率最高的一種項目開發(fā)方式。
發(fā)布完畢后，master主分支還繼續(xù)做項目下一個功能版本的開發(fā)工作。如果線上代碼出現(xiàn)bug，那么就在master分支上修復(fù)就可以了。
特征
- 項目所有主要/核心功能代碼的開發(fā)工作都在master分支上，開發(fā)完畢后，在master分支上進行集成測試 。
- 項目代碼測試通過后，通過打標(biāo)簽的方式，以標(biāo)簽的方式進行代碼發(fā)布。
- 項目正常運行過程中出現(xiàn)bug，在master分支進行bug的修復(fù)工作，修復(fù)代碼通過測試后，打標(biāo)簽發(fā)布。
優(yōu)勢：
- 項目代碼發(fā)布前，需要進行主干集成測試，代碼沖突易于提前發(fā)現(xiàn)
- master主干代碼安全穩(wěn)定，每次測試通過后，都可以隨時發(fā)布。
- 集成測試常見的配套措施：每日集成(編譯部署測試)，代碼檢查，單元/接口/界面自動化測
劣勢：
新功能代碼在master主干上開發(fā)，若主干代碼達不到穩(wěn)定的標(biāo)準，不可以進行項目發(fā)布master上主干開發(fā)有先后，有未完成的功能但又需要發(fā)布時，需要能隱藏未完成部分。 為了避免以上情況，有三種緩解方法：
1)功能拆分，小批量頻繁發(fā)布；
2) 后端先行，ui或功能入口發(fā)布；
3) 功能開發(fā)，配置決定功能
分支發(fā)布
項目的功能開發(fā)工作在master分支上，代碼開發(fā)完畢后，經(jīng)過功能測試沒有問題后，從master主分支上切出一個release分支，作為項目代碼版本發(fā)布的專用分支，而master分支還繼續(xù)做項目下一個功能版本的開發(fā)工作。
如果線上代碼出現(xiàn)bug，那么就在release分支上修復(fù)就可以了，修復(fù)后的代碼最終要合并到主干上，只有非常嚴重的缺陷修復(fù)才會從master合并到release分支上。
優(yōu)勢：
主干開發(fā)的過程中，關(guān)于分支合并的工作量很少，所以整體比較簡單，且更容易發(fā)布
劣勢：
線上出現(xiàn)歷史嚴重bug,需要在各該分支上各個修復(fù)，直接在master修復(fù)后同步到各分支容易有各沖突
Git-Flow
Git_flow是一種代碼分支管理規(guī)范，其實它屬于一種主干開發(fā)—主干發(fā)布類型。遵守的Git-Flow規(guī)范的分支分為兩種，長期分支和短期分支。該工作流相對復(fù)雜，需要同時維護兩個長期分支，開發(fā)中需要經(jīng)常切換分支
長期分支
1. 主分支master
1. 線上所有功能代碼所在，只讀不可修改，對外發(fā)布的唯一分支。
2. 只能由hotfix或develop合并
2. 開發(fā)分支develop
1. 基于master 分支克隆，只讀不可修改。
2. feature分支從該分支拉出，開發(fā)完成后合并到develop
3. 分支上的功能經(jīng)測試無誤后，需要由該分支再次合并到master分支上。
短期分支
一旦開發(fā)完成就會合并到develop和master分支上，然后被刪除。
1. 功能分支（feature branch）
1. 功能開發(fā)分支 , 基于 develop 分支克隆 , 主要用于新需求新功能的開發(fā)，屬于臨時分支
2. feature 分支可同時存在多個 , 用于團隊中多個需求功能同時開發(fā)
3. 功能開發(fā)完畢并測試完成后合到 develop 分支。合并后此分支刪除(誰合并誰刪除)
2. 補丁分支（hotfix branch）
1. 基于 master 分支克隆 , 主要用于對線上的版本進行bug修復(fù)，屬于臨時分支
2. 修復(fù)完畢后，如果需要臨時發(fā)版則需要打tag并推送到master/develop分支，如果不需要發(fā)版只需要推送到develop分支且不用打tag
3. 預(yù)發(fā)分支（release branch）
1. 用于提交給測試人員進行功能測試 , 測試過程中發(fā)現(xiàn)的 BUG 在本分支進行修復(fù) , 修復(fù)完成上線后打tag并合并
2.從 develop 分支克隆，屬于臨時分支。提測完成后合并到master/develop分支，然后刪除該分支(誰合并誰刪除)。
GitHub-Flow
Github flow 是Git flow的簡化版，專門配合”持續(xù)發(fā)布”。它是 Github.com 使用的工作流程。在持續(xù)發(fā)布模式下，master和develop分支其實差異不大，所以GitHub-Flow工作流只有一個長期分支master。
github-flow與git-flow區(qū)別
- github-flow只有一個長期分支master
- github-flow沒有release分支，需求功能直接在feature分支上測試完畢merge到master，然后再master分支上進行發(fā)布
- 每次feature分支merge到master上時可能會有沖突，這要求在feature發(fā)布前需要合并一線master代碼到feature上，進行提測測試。
總結(jié)
github_flow模式的工作流一般更貼近日常開發(fā)工作，根據(jù)自身項目的發(fā)布特點可以進行差異化的調(diào)整，適合自己的才是最好的。
相關(guān)鏈接：
- 項目開發(fā)混淆從初識到理解
- 項目開發(fā)代碼分支管理
擴展鏈接：文章來源：http://www.zghlxwxcb.cn/news/detail-403441.html
- Material Design UI方案使用講解
- Material TextInputLayout使用詳解
博客書寫不易，您的點贊收藏是我前進的動力，千萬別忘記點贊、 收藏 ^ _ ^ !文章來源地址http://www.zghlxwxcb.cn/news/detail-403441.html
到了這里，關(guān)于項目開發(fā)代碼分支管理的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
