1.GIT Flow流程圖

在使用Git的過程中如果沒有清晰流程和規(guī)劃，否則,每個人都提交一堆雜亂無章的commit,項目很快就會變得難以協(xié)調(diào)和維護(hù)。
Git版本管理同樣需要一個清晰的流程和規(guī)范。
Vincent Driessen 為了解決這個問題提出了GIT FLow
以下是基于Vincent Driessen提出的Git Flow 流程圖

GIT Flow時間流程圖.png

2.Git的分支簡介

下面分支中提到的version應(yīng)該替換為具體的版本，name應(yīng)該替換為具體的開發(fā)人員姓名，content應(yīng)該替換為需要優(yōu)化的地方

2.1master分支

git的默認(rèn)分支，主分支，一般不會輕易改動，上面的代碼為生產(chǎn)環(huán)境的最新發(fā)布版本。在新版本發(fā)布后，將新版本代碼合并到該分支，并在該分支上打tag標(biāo)簽,這個分支只能從其他分支合并，不能在這個分支直接修改

2.2develop分支

通常創(chuàng)建git項?目的同時就創(chuàng)建 develop ，是開發(fā)人員?的主要分支，以 master 為分?來源。其最新代碼代表著開發(fā)?員為下一個發(fā)布版本提交的最新代碼。不能代表最新的特性代碼，也不代表正在發(fā)布的版本代碼。

Develop.png

2.3feature分?

feature 分支，即新功能分支(有時也稱之為特性分支)，主要被用于即將開發(fā)的或更長期的功 能開發(fā)。它有可能被合并到 develop 分支或者被廢棄掉。

feature.png

2.4release分?

當(dāng)你需要一個發(fā)布一個新Release的時候，我們基于Develop分支創(chuàng)建一個Release分支，完成Release后，我們合并到Master和Develop分支,release 分支專供測試使用，允許我們在發(fā)布前，做最后?點(diǎn)點(diǎn)改動，比如元數(shù)據(jù)(如版本信息、編譯參數(shù)等)的修改等。

image.png

2.5release-fix分?

release-fix分支用于解決測試人員對release代碼分支提出的BUG。

2.6Hotfix分支

當(dāng)我們在Production發(fā)現(xiàn)新的Bug時候，我們需要創(chuàng)建一個Hotfix, 完成Hotfix后，我們合并回Master和Develop分支，所以Hotfix的改動會進(jìn)入下一個Release
fix分支用于解決生產(chǎn)環(huán)境發(fā)現(xiàn)的BUG。標(biāo)準(zhǔn)的該分支一般命名為hotfixes,Android版中為了區(qū)分熱修復(fù)而重命名。

Hotfix.png

2.7 refactor(feature)

refactor分支用戶重構(gòu)和優(yōu)化代碼，區(qū)別于修改 fix 分支，refactor分支不一定會在下一個版本中上線，而 fix分支一定會在下一個版本中上線。

3.使用示例

市面上的公司基本上都是使用給流程，只不過命名方式上有可能不同

使用示例圖.png

4.創(chuàng)建項目的經(jīng)過

創(chuàng)建 master 分支，然后基于 master 創(chuàng)建出 develop 分支。

4.1新功能開發(fā)

1. 基于 develop 分支，創(chuàng)建 feature-version 分支，如果開發(fā)人員少，可以都在 feature-version分支上進(jìn)行開發(fā)。如果開發(fā)人員比較多，基于feature-version 分支繼續(xù)創(chuàng)建每個人的單獨(dú)開發(fā)分支，命名如 feature-version-name。
2. 完成開發(fā)。
3. 聯(lián)調(diào)代碼，完成自測。
4. 如果有多個 feature 分支，將其全部合并到 feature 分支，然后拉取 develop 分支的代碼到 feature分支，解決可能存在的沖突，然后提交 MR 到 develop 分支，刪除 feature 分支。剩下操作參照[11.3.3 測試新功能)](#11.3.3 測試新功能)。

補(bǔ)充說明：feature-version 分支上開發(fā)時 在單獨(dú)的開發(fā)分支上可以commit和push代碼進(jìn)行同步代碼，只是在該迭代開發(fā)完成后才進(jìn)行合并代碼(MR)到develop,此時沒有push權(quán)限,只能請求合并權(quán)限(MR)，MR在gitlab中操作。

4.2測試新功能

1. 檢查 MR 到 develop 上的代碼，確認(rèn)后，同意 MR。
2. 在 develop 分支上創(chuàng)建 release-version 。
3. 檢查 MR 到 release-version 上的代碼，確認(rèn)后，同意 MR，修改應(yīng)用 versionCode 和 versionName，在 release-version 上打測試環(huán)境的安裝包，提交給測試人員進(jìn)行測試。
4. 如果測試人員發(fā)現(xiàn)BUG，基于 release-version 分支創(chuàng)建 release-fix-version分支，修復(fù)BUG，修復(fù)完成后，提交MR 到 release-version，刪除 release-fix-version分支。
5. 重復(fù)進(jìn)行步驟3、4，直到測試通過。

4.3發(fā)布新功能

1. 基于 release-version 分支打正式包，提交到應(yīng)用市場。
2. 提交 MR 到 master 分支，同意后，在 master 分支上打 對應(yīng)版本的 tag。
3. 提交 MR 到 develop 分支。
4. 刪除 release-version 分支。

4.4修復(fù)線上BUG

1. 定位到 BUG 產(chǎn)生的地方，基于 master 分支 創(chuàng)建 fix-version 分支修復(fù) BUG，這里的 version 為 BUG 產(chǎn)生的分支。
2. 修復(fù)完成后，提交 MR 到 release-version 上。
3. 檢查 MR 到 release-version 上的代碼，確認(rèn)后，同意 MR，在 release-version 上打測試環(huán)境的安裝包，提交給測試人員進(jìn)行測試。
4. 如果測試人員發(fā)現(xiàn)BUG，基于 release-version 分支創(chuàng)建 release-fix-version分支，修復(fù)BUG，修復(fù)完成后，提交MR 到 release-version，刪除 release-fix-version分支。
5. 重復(fù)進(jìn)行步驟3、4，直到測試通過。
6. 如果 BUG 十分嚴(yán)重，需要馬上發(fā)版，則修改應(yīng)用 versionCode 和 versionName，剩下操作參照[11.3.4 發(fā)布新功能)](#11.3.4 發(fā)布新功能)。如果不嚴(yán)重，則提交 MR 到 develop 分支。

4.5重構(gòu)代碼

1. 基于 develop 分支，創(chuàng)建 refactor-content 分支。
2. 完成優(yōu)化。
3. 測試優(yōu)化。
4. 提交 MR 到 develop 分支。

5.代碼評審

在兩個及兩個以上開發(fā)人員的項目中，應(yīng)該進(jìn)行代碼評審，檢查代碼風(fēng)格和是否有潛在的BUG。
MR時需要做簡易Code Review,項目發(fā)布后做詳細(xì)Code Review 之后在重構(gòu)分支上合并,此分支測試后手于Master合并，測試風(fēng)險控制)

6.Android studio提交規(guī)范

git commit --amend  //提交后會與最后一次提交進(jìn)行合并生成一個新的提交，之前的提交會被廢棄掉。

修改的文件已被git commit，但想再次修改不再產(chǎn)生新的Commit.

git commit --amend -m"說明"

目的：如果你仍然有文件沒有提交，想追加到最后這個commit上的話，用上述命令，可以保持commit提交歷史的干凈性。
代碼更新及提交規(guī)范小結(jié)：先執(zhí)行Pull拉取服務(wù)器最新代碼，更新時選擇“Merge”和“Using Stash”,最后Commit和push到相應(yīng)分支。

如果先創(chuàng)建本地提交，然后在執(zhí)行更新操作，這樣會導(dǎo)致Git自動生成一個合并提交，導(dǎo)致提交歷史不夠簡潔。

擴(kuò)展合并 commit 保持分支干凈整潔

7主庫權(quán)限管理

項目權(quán)限分配：

Owner：擁有主庫的所有權(quán)限。

Committer：具有將開發(fā)人員的合并請求（MR）合入主庫的權(quán)限。基于安全考慮，我們設(shè)置為只能通過MR的方式將代碼合入主庫，而不能直接push到主庫。

Developer：只能從自己的個人代碼庫（服務(wù)端）提交合并代碼的請求（MR），是否能夠合入，由Committer進(jìn)行審核。

7.1git分支管理中用到的命令匯總

預(yù)發(fā)布分支

• 創(chuàng)建一個功能分支(feature-x)并切換到當(dāng)前分支：

git chechout -b feature-x (develop)

• 開發(fā)完成后，將功能分支合并到develop分支：

git checkout develop 

git merge --no-ff feature-x

//注意：切換分支前 記得先緩存 stash

• 刪除feature分支：

//刪除本地分支
git branch -d feature-x //如果分支上的代碼沒有合并，會失敗
git branch -D feature-x //強(qiáng)制刪除
//刪除遠(yuǎn)程分支
git push origin --delete feature-x
//or
git push orgin :feature-x （origin有空格） 

//查看remote地址，遠(yuǎn)程分支，還有本地分支與之相對應(yīng)關(guān)系等信息
 git remote show origin
//在本地刪除遠(yuǎn)程不存在的分支
git remote prune origin

注：刪除前 本地分支不能是即將要刪除的分支 ,需要先切換到不同分支后再刪除其他分支，不能當(dāng)前分支刪除所在的分支。

• 創(chuàng)建一個預(yù)發(fā)布分支(release-1.x)：

git checkout -b release-1.x develop

• 確認(rèn)沒有問題后，合并master分支：

git checkout master

git merge --no-ff release-1.x

• 對合并生成的新節(jié)點(diǎn)，做一個標(biāo)簽

git tag -a V1.x -m "標(biāo)簽說明"

• 再合并到develop分支：

git checkout deveop

git merge --no-ff release-1.x

• 最后，刪除預(yù)發(fā)布分支：

git branch -d release-1.x

修復(fù)分支

• 創(chuàng)建一個修補(bǔ)bug分支：

git checkout -b fix-0.1 master 

• 修補(bǔ)結(jié)束后，合并到master分支：

git checkout master

git merge --no-ff fix-2.x

git tag -a 2.x

再合并到develop分支

git checkout develop

git merge --no-ff -fix-2.x

最后刪除 修補(bǔ)bug 分支

git branch -d fix-2.x

其他：如本地緩存策略、回滾（慎用）等等。

//存儲你的工作區(qū)間
git stash 
//查看存儲列表
git stash list
//應(yīng)用相應(yīng)的緩存列表
git stash apply --index

8.避免代碼沖突Tips

為了盡量避免沖突發(fā)生，養(yǎng)成如下開發(fā)習(xí)慣：

• 編碼前先更新
• 提交前先更新
• 提交前檢查是否有編譯錯誤
• 提交粒度盡可能小，描述盡可能準(zhǔn)確
• 修改了公共文件，盡早通知其他成員更新
• 最后一條，也是最重要的，團(tuán)隊分工要明確

9.Andorid迭代開發(fā)中g(shù)it使用示例

9.1 準(zhǔn)備開始

應(yīng)用場景示例：下面即將開始版本號1.8.0的迭代開發(fā)工作。
創(chuàng)建 master 分支，然后基于 master 創(chuàng)建出 develop 分支。(此處操作往往在上一次開發(fā)結(jié)束后就已完成)
基于 develop 分支，創(chuàng)建 feature-1.8.0（迭代版本號）迭代開發(fā)分支

git checkout -b feature-1.8.0

創(chuàng)建好后 立即push到服務(wù)器。

如果沒有push前，pull(更新)會失敗，因為無法追蹤當(dāng)前分支，當(dāng)前分支不在遠(yuǎn)程服務(wù)器上。
無論push成功還是失敗，都會出現(xiàn)提示

9.2開發(fā)中

小組成員之間都有該分支 的pull和push權(quán)限。開發(fā)中按照Git提交規(guī)范和Android studio提交規(guī)范執(zhí)行。

git提交命令分類如下：
feat： 新功能（feature）
fix： 修復(fù)bug
docs： 文檔（documentation）
style： 格式（不影響代運(yùn)行的變動）
refactor： 重構(gòu)（既不是新增功能，也不是修改bug的變動）
test： 增加測試
chore： 構(gòu)建過程、輔助工具、編輯器配置的變動
操作提示：
fix(首頁)：修復(fù)緩存異常
feat(用戶)：新增修改用戶頭像的功能

9.3 開發(fā)完成

準(zhǔn)備提交測試。開發(fā)完成后，將功能分支合并到develop分支。

目的：將當(dāng)前的開發(fā)分支（如feature-1.8.0）合并到develop分支

操作方法：在GitLab主頁中去操作，創(chuàng)建合并請求（MR），操作步驟見下文。

權(quán)限管理： 涉及到安全、權(quán)限、流程規(guī)范等因素，不能直接用git命令合并。所以需要在GitLab中去MR。

下面介紹常用的兩種代碼合并方式。

9.3.1 方式一：無權(quán)限設(shè)置

如果不涉及到權(quán)限、審核等安全因素，可以直接用以下操作用命令或Android stutdio上操作。

git checkout develop 

git merge --no-ff feature-x

9.3.2 方式二：有權(quán)限設(shè)置

團(tuán)隊開發(fā)按照流程規(guī)范我們統(tǒng)一采用方式二。

權(quán)限設(shè)置如下所示，可以設(shè)置各個分支的權(quán)限。

此處的設(shè)置一般會放在Git流程規(guī)范形成后，開發(fā)迭代任務(wù)前完成。開發(fā)過程中檢查一次即可。

在這里插入圖片描述

創(chuàng)建MR步驟

1.在項目的倉庫主頁中找到Create Merge request

在這里插入圖片描述

2.填寫請求內(nèi)容

注意Title和內(nèi)容的的填寫規(guī)范：可參考《MR注釋規(guī)范》

MR注釋規(guī)范

在這里插入圖片描述

在這里插入圖片描述

查看MR中的具體代碼改變了哪些。

在這里插入圖片描述

注意寫明請求內(nèi)容，分支來源和目標(biāo)分支。最后“提交”。到此，MR完成。

3.處理MR(Merge Requests)

緊接著，會郵件通知委托人，進(jìn)行MR處理，確認(rèn)沒有問題時，會通過，合并完成。如果發(fā)現(xiàn)有問題，則關(guān)閉請求，合并失敗，需要請求人修改代碼后重新MR.

在這里插入圖片描述

回到Android studio中，查看git log操作記錄?？梢园l(fā)現(xiàn)已經(jīng)合并完成。此時develop上已經(jīng)合并了feature-1.8.0的最新代碼。

在這里插入圖片描述

OK,開始打包預(yù)發(fā)布測試版本。

9.4 預(yù)發(fā)布

由于此前的迭代開發(fā)分支feature-1.8.0的代碼已合并到develop上?，F(xiàn)在develop創(chuàng)建 release-1.8.0 。

git切換到release-1.8.0打測試環(huán)境的安裝包給測試。

操作示例：

1.創(chuàng)建release-1.8.0 并切換到當(dāng)前分支

git checkout -b release-1.8.0

2.打包（測試環(huán)境）（打包命令需要在build.gradle中配置）

Mac環(huán)境：./gradlew clean resguardCtest 

Windows環(huán)境：gradlew clean resguardCtest

9.5 Bug修復(fù)

測試反饋難免會有bug或細(xì)節(jié)調(diào)整，此時需要創(chuàng)建修復(fù)分支，方法如下：

1.基于release-1.8.0創(chuàng)建 release-fix-1.8.0_1 同時記錄修復(fù)次數(shù)。注：最后一位數(shù)字表示修復(fù)次數(shù)。

git checkout -b release-fix-1.8.0_1

2.修復(fù)完成后，提交MR到release-1.8.0,在提交MR時刪除release-fix-1.8.0_1。同時在release-1.8.0打包測試。在當(dāng)前分支打包 流程細(xì)節(jié)參考預(yù)發(fā)布流程。

3.重復(fù)進(jìn)行步驟1、2，直到測試通過。

小結(jié)： 實際開發(fā)中，可以根據(jù)實際需要減少重復(fù)的開發(fā)分支的合并和建立，注意在git上記錄操作節(jié)點(diǎn)，方便后期查詢追蹤。

9.6 發(fā)布App

最后一次給測試的包測試環(huán)境通過后，需要打正式環(huán)境的包，提交應(yīng)用市場。

操作示例：

1.切換到發(fā)布分支release-1.8.0

git checkout release-1.8.0

2.打包（正式環(huán)境）

Mac環(huán)境：./gradlew clean resguardRelease

Windows環(huán)境：gradlew clean resguardRelease

打包成功后，生成的母包 用python命令打包成對應(yīng)App市場的渠道包，準(zhǔn)備進(jìn)行分發(fā)，上傳應(yīng)用市場。

3.代碼合并、tag管理、刪除多余分支

• 提交 MR 到 master 分支，同意后，在 master 分支上打 對應(yīng)版本的 tag(v1.8.0)。

• 提交 MR 到develop分支。

• 刪除 release-1.8.0 分支。 最后git上只有master 、develop分支和tag歷史版本記錄。

至此，當(dāng)前迭代開發(fā)工作結(jié)束。開始準(zhǔn)備創(chuàng)建分支重構(gòu)代碼、線上bug修復(fù)等等。

總結(jié)： git的使用規(guī)范在項目開發(fā)至關(guān)重要，文中的使用示例 是在項目中的實際操作總結(jié)。以上，供你參考。
https://blog.csdn.net/jun5753/article/details/97135871