git工作流應(yīng)用場景分析

這篇文章主要介紹“git工作流應(yīng)用場景分析”，在日常操作中，相信很多人在git工作流應(yīng)用場景分析問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”git工作流應(yīng)用場景分析”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

規(guī)范化的git流程能降低我們的出錯概率，也不會經(jīng)常遇到git問題，然后去搜一堆git高階用法。我們的這套git玩法兒，其實只要會基本的git操作就行了，然后規(guī)范化操作，基本不會遇到git問題，這樣大家就可以將時間用于業(yè)務(wù)上。最終，希望大家研究git的時候是在感興趣的時候，而不是遇到問題，緊急去尋找答案的時候

我們的這種git工作流玩兒法呢，主要是分為下面幾個分支：

• master分支   最新的穩(wěn)定代碼

• vx.x.x分支   版本分支，x.x.x是此次開發(fā)的版本號。

• feat-xxx分支 特性（新的功能）分支

• fix-xxx分支  修復(fù)分支

上面的這些分支呢，就是我們在開發(fā)中需要經(jīng)常去創(chuàng)建并使用的分支。下面詳細(xì)說說每個分支代表的意思。

master分支代表的是最新的穩(wěn)定版本的代碼，一般是版本分支或者修復(fù)分支的代碼上線后合并過來的。

feat-xxx分支表示的是為開發(fā)某個版本的某個新功能而創(chuàng)建的分支。

vx.x.x代表的是版本分支，這個是我們在每個版本開始前，以此次版本號為名從master創(chuàng)建的分支，比如版本號是 2.0.1，那么版本分支則為 v2.0.1。然后等到該版本的各個新功能在feat-xxx開發(fā)完成并冒煙測試通過后，就到gitlab上提一個mr合并到該版本分支上。等到各個環(huán)境測試通過后，就將版本分支的代碼合并到master上，然后就可以刪除本次的版本分支了。

fix-xxx表示的是修復(fù)分支，通常在處理線上問題時，創(chuàng)建一個以缺陷名稱命名的分支，在缺陷測試通過后，通過mr合并到master分支去

注意：這里有個細(xì)節(jié)是，在特性分支上開發(fā)提交的commit信息，一般認(rèn)為是無用信息，會在合并給版本分支的時候給合并到一個commit（由于我們是使用gitlab來合并，所以在發(fā)起mr請求時勾選squash選項就好了），而在提測后不論是修復(fù)測試過程中bug，或者是優(yōu)化功能的commit則會全部保留，這個目的是一個警示，因為我希望最好的情況是提測即上線，雖然達(dá)到這個目標(biāo)有難度，但是這些留下的commit信息可以幫助我們復(fù)盤

各個分支的作用如上面所描述的那樣，接著聊聊我們開發(fā)的一些經(jīng)典場景該怎么做：

第一個場景：正常開發(fā)迭代

我們以本次需要開發(fā)一個 1.0.0版本為例，這個其中有兩個功能模塊，一個是需要添加一個按鈕，一個是需要添加一個表格

sequenceDiagram
master->>v1.0.0: 從master切出 v1.0.0
master->>feat-add-button: 從master切出 feat-add-button
master->>feat-add-form: 從master切出 feat-add-button
feat-add-form->>feat-add-form: 開發(fā)完成
feat-add-button->>feat-add-button: 開發(fā)完成
feat-add-button->>v1.0.0: 在gitlab發(fā)起mr到v1.0.0,并合并所有commit
feat-add-form->>v1.0.0: 在gitlab發(fā)起mr到v1.0.0,并合并所有commit
v1.0.0->>v1.0.0: 提測
feat-add-button->>feat-add-button: 修復(fù)測試bug
feat-add-button->>v1.0.0: 將修復(fù)的 commit cherry pick到 v1.0.0
v1.0.0->>master: 在gitlab上mr到master，并將合并信息改成 v1.0.0

通過上面的時序圖，可以看到，我們以我們即將開始的版本命名了一個版本分支 v1.0.0,并且也根據(jù)這個版本下面的兩個功能創(chuàng)建了兩個特性分支 feat-add-button和feat-add-form,然后等功能開發(fā)完成后再通過gitlab發(fā)起mr（注意，這里要把合并commit選項勾選上）合并到 v1.0.0,那么 v1.0.0分支的代碼就會從dev環(huán)境開始流轉(zhuǎn)，直到生產(chǎn)環(huán)境。這其中，如果有需要修復(fù)或者優(yōu)化的地方，也是先修改特性分支，然后再cherry pick到版本分支上面。上線以后刪除版本分支以及下面的特性分支。

通過這個流程管理的代碼版本非常清晰，這是截取的master的一部分片段

在正常迭代流程還有個場景。那就是在開發(fā)過程中，pm突然過來說，因為某種不可抗力，有一個功能需要砍掉。這個時候，如果是代碼還沒提測，亦或者是功能比較簡單，處理起來還不算麻煩。但如果是，你的功能和其他同事的代碼已經(jīng)在測試了，并且也已經(jīng)修復(fù)了一些bug，commit都交叉在一起，特別是那種涉及修改文件還多的需求，這個時候處理起來就很麻煩，不僅要看著別人的代碼，還得警惕自己的代碼別弄錯了。那這個時候，在我們流程里就很簡單，直接刪除現(xiàn)有的版本分支就好了，再重新將需要上線的特性分支組合在一起就可以了?？梢钥吹?，版本分支是由特性分支組合起來的，也就是說，版本分支可以由不同的特性分支隨意組合。這樣處理起來就比較方便

第二個場景 線上bug修復(fù)

我們以線上需要修復(fù)一個按鈕的點擊事件為例

sequenceDiagram
master->>fix-button-click: 從master切出 fix-button-click
fix-button-click->>fix-button-click: 修復(fù)問題并測試
fix-button-click->>master: 從gitlab發(fā)起mr合并到master

其實這里的流程跟上面沒多大的區(qū)別，但是這里需要注意的是，線上問題修復(fù)，一個bug一個commit，合并到master的時候不合并commit。而且需要將合并信息修改為本次的版本號。比如本次則為 v1.0.1

第三個場景 多版本并行開發(fā)

這個場景跟正常迭代場景并沒啥區(qū)別，只是取決于你有多個版本，就創(chuàng)建對應(yīng)的版本分支就可以了。每個版本分支按照正常迭代流程就可以了。

Q&A

Q：為什么沒有使用dev、test等對應(yīng)環(huán)境的分支，這樣也好實現(xiàn)push既部署

A：我們這個流程是放棄了使用這些固定的分支的。有幾個原因，

• 代碼提測后從dev到test，甚至再到uat（預(yù)發(fā)布）環(huán)境，如果在不同的環(huán)境都有代碼的變動，那么為了保持這些分支代碼一致的話，就需要將代碼同步到各個環(huán)境分支，這點兒有些費事兒。而版本分支不存在這個問題，版本分支只有一個，可以對應(yīng)到各個環(huán)境。

• 方便多版本并行開發(fā)。版本分支可以創(chuàng)建多個，并行開發(fā)的時候比較方便部署到不同的測試環(huán)境。如果版本之間的模塊關(guān)聯(lián)性不大，還可以并行測試。

• 語義化。版本分支可以通過分支名稱就知道目前有哪些分支正在開發(fā)中。

Q: master分支有變動怎么處理

A: master分支有變動的話，及時的合并到自己的功能分支上，以防和其他成員代碼有沖突

到此，關(guān)于“git工作流應(yīng)用場景分析”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>