2024-02-06|閱讀時間 ‧ 約 26 分鐘

後端技術考古題-開發工具 中篇

    ※ 主題關鍵字

    • Git flow:
    raw-image


    說明:

    1. Git Flow 是一種基於 Git 版本控制系統的擴展,用於協助團隊進行項目的軟體開發和版本管理,就流程來說屬於概括性的流程
    2. 這種工作流程定義了一組明確的分支模型,以協助有效地進行功能開發、修復錯誤和發布版本。
    3. Git Flow 可以針對不同的開發環境建置不同的測試或正式版本。
    4. 在Git Flow流程下,不同開發者可以同時開發不同功能,或者同時一起開發一個大功能。當開發和發佈同時進行時,彼此將不受影響。因此整個開發過程中,會有良好的共同程式開發和版本控制協作流程。
    5. 透過Git Flow所創造出一個具統一性、受規範、自動化(搭配 CI/CD)的開發流程,可以減少人為犯錯的風險、同時提升效率。

    Git Flow五種分支的介紹:

    • 兩個長期存在的分支,且絕對不會被刪除:
    1. 主分支Master。
    2. 開發分支Develop。
    • 三種短期(臨時性)分支。開發完畢被merge進develop或master後就會被刪除的分支:
    1. 功能分支(feature branch)。
    2. 預發分支(release branch)。
    3. 修復分支(hotfix branch)。


    Git Flow包含五種分支負責處理不同的功能:

    1. Master: Master分支會專門放正式發布版本或隨時可以上線的版本。
    1. Developer: 用來存放最新開發版本的代碼,是開發過程中代碼的中心分支。開發人員通常會以Developer這條分支為基礎,再開出Feature分支進行新功能的開發,當Feature的功能開發完畢,Feature的分支會合併回Developer。
    1. Feature:Feature分支裡面主要是用來處理開發新功能,會是基於Developer分支開出來,功能完成時,再把開出來的Feature分支合併回Developer分支。
    1. Release:用於支援準備發佈正式產品前的預備分支。允許修正小問題,並為發布版本準備或修改中介資料。
    2. HotFix:在Master分支中出現重大錯誤時,可以直接從Master分支建立HotFix分支來快速實施錯誤修正。



    • GitHub flow

    整個 GitHub Flow 是基於主分支的一種輕量化工作流程,屬於 Git 的核心概念,目的在幫助團隊及專案定期的進行部署。它重點在於簡單、靈活且容易理解,特別適用於需要快速反應和頻繁交付的專案。

    使用說明:

    先有一個共有的遠端倉庫,然後各自用fork把遠端倉庫fork回到自己的倉庫。開發好後,再利用PR(pull request)回去共有的遠端倉庫,審核過後merge(合併)進master。


    ※ GitHub Flow 的主要特點:

    1. 主分支(Main Branch): GitHub Flow 使用一個主分支,通常命名為 mainmaster,用於代表產品的穩定狀態。這是所有發布版本的基礎。
    2. 建立分支(Branching): 每當需要測試新功能、修復錯誤或進行任何其他工作時,團隊成員會在主分支的基礎上創建一個新的分支。這個分支將包含他們所進行的更改。分離出的新分支對 master 來說是非常重要的,因此分支命名應該具有描述性,讓其他人清楚知道分支正在進行的工作項目。

    建立分支


    1. 提交(Commits): 在分支上進行工作時,開發者將其更改進行提交(commit)。每次提交都應該要有相關的提交訊息(Commits Message),解釋此次提交內容。

    Add Commits

    2. 拉取請求(Pull Requests): 當在分支上完成一項任務時,開發者會向主分支提出拉取請求(pull request)。Pull Request 是一個通知團隊進行代碼審查、討論和測試的機會,因此對於協作開源專案和管理共享儲存庫的修改非常有用。

    1. 代碼審查(Code Review): 團隊成員將檢查拉取請求中的更改,提供反饋並確保代碼符合標準。這有助於確保代碼的質量和一致性。

    拉取請求和代碼審查

    4. 合併(Merge): 一旦拉取請求經過審查,並經過必要的更改和測試,就可以將其合併到主分支中。

    合併

    5. 部署(Deploy): 已經被檢閱且通過測試的分支被合併到主分支上後,將被部署為生產版本,形成新的軟體發布。

    部署(Deploy)

    ※總結:

    • 所有在 master 分支都是可部署(Deployable)的。
    • 要增加新功能時,從 master 開一個此新功能的分支,分支命名應該具有描述性。
    • 需要回饋、幫助時,或是當完成新功能要合併(Merge)回 master 分支時,請使用 Pull Request。
    • 經過審查、測試過後,就可以合併回 master 分支。
    • 合併之後就可以馬上部署程式碼。



    • 什麼是 rebase:

    說明: 

    1. rebase是 Git中的一個操作,主要用於合併分支或整理提交歷史。
    2. rebase 簡單來說就像「移花接木」,把你的分支接到別的分支上。

    _images/rebase.png

    以上圖來說,就是把 New Branch 的變更整個接到 Master 上。

    • Rebase 的使用時機:
    1. 整理提交歷史:rebase 可以對提交歷史進行清理和整理。
    2. 將一個分支的修改整合到另一個分支:使用 rebase有助於保持歷史的簡潔性,避免不必要的合併提交。
    3. 解決合併衝突:在進行 rebase 時,會發生合併衝突。當解決衝突後,可以繼續應用剩下的修改。
    4. 避免合併提交:使用 rebase 可以避免產生大量的合併提交,可以讓提交歷史更加緊湊,更容易理解。
    5. 在提交到遠端之前整理分支歷史: 在推送分支到遠端之前,進行 rebase 可以確保提交歷史的整潔性,避免向遠端推送不必要的合併提交。


    分享至
    成為作者繼續創作的動力吧!
    © 2024 vocus All rights reserved.