一千萬個為什麽

搜索

如何擺脫簡化Git流程的開發分支



在一個不斷開發的Web項目中(不是產品),我們目前有以下分支策略,大致基於 git flow

  • 開發分支:最新工作版本
  • 主分支:要發布/發布的版本
  • 功能分支:開發中的功能
  • 修補程序分支:發布版本中的緊急錯誤修復

Master is read only, updated via pull requests from develop or hotfix branches. Each update results in a release candidate being built and deployed to the staging system. Release candidates are deployed to production after manual approval.

Feature branches are created based off develop, or from the last commit that has been merged into master. A pull request from a feature branch to develop is built, deployed to a free test system where integration tests and acceptance tests (automatic & manual) are executed. When successfully tested and reviewed, the PR gets merged, so that it will become part of the next release (i.e. merge from develop to master).

我的目標

我想簡化這個並擺脫開發分支。開發分支主要是歷史原因,因為它始終是一個成功測試版本,我認為沒有必要將它與主分離。刪除它也將簡化發布過程,因為不再有任何額外的合並。

我有以下限制:

  • 發布計劃,不應該完全自動化
  • 雖然功能分支通常是短暫的,但有些會在幾周內未被合並(例如重新設計),但也需要進行測試(目前作為開放的請求來開發)
  • 有時應該在常規版本之外發布單個功能,從而有效地將其轉換為修補程序。通過目前的策略,我可以重新綁定一個功能分支並將其直接合並到主服務器中
  • 在分段失敗的外部系統進行驗收測試後,我們還需要阻止功能

我不確定過渡的地方:

  • 目前,我正在構建用於測試的合並請求並合並提交發布。我可以統一這個嗎?
  • 當主服務器領先於最新版本時,如何處理修補程序。我應該直接從修補程序分支構建和部署發行版嗎?
  • 是否有一種明智的方式來處理應該在已經合並後從發布中排除的功能?對於這些情況,單獨的開發分支真的是一個優勢嗎?大多數情況下,我最終都會手動恢復並重新提交提交。

轉載註明原文: 如何擺脫簡化Git流程的開發分支

一共有 4 個回答:

假設您取出主分支(如果您以後喜歡,可以將開發人員重新命名為混淆您的團隊),並簡單地在開發版或修補程序分支上使用標簽進行發布。你拿出了一個分支,但區別只是語法上的變化。為了變化而變化。

現在讓我們假設你實際上保留了鎖定的主分支。將會發生的一點是,代碼集成將會變慢,它將在功能分支中更長壽,特別是接近發布日期。這會增加每次合並的難度,並減慢過程。

在你制定的限制條件下,我沒有看到做出這種改變的任何積極影響。這需要放寬限制,特別是第一個限制。

您已經在每個拉取請求和熱修復分支上構建和測試代碼。這意味著總的來說,所有待處理的分支請求都是你的虛擬 develop 分支。

您可以在測試環境中創建一個系統,將多個拉取請求挑選到未發布到主存儲庫的臨時分支中。該分支用於集成包含 master 和多個附加pull請求的測試環境,但是一旦測試完成,該分支不再可用。

當您從 master 創建發行版時,通常會在該發行版上創建一個標簽。即使 master 的邊緣已經位於前面,以後的修補程序也可以使用該標記創建將從中進行部署的新修補程序分支。在此修補程序分支上,您可能還會標記次要版本,並確保將更改合並到 master 中。

從版本中刪除合並的功能與git很難做到。最好的機制是在合並提交時使用 git revert 。但是這使得幾乎不可能獲得這些功能/變化,歷史變得混亂。

A much better way to handle separation for deployment of code, and release of features, is feature flags. If your developers can hide their features behind some conditions in the code itself, you could deploy their code, but turn off the feature. This is a separate topic, but a lot of information about this exists (including a Q&A on devops.SE).

恕我直言,您面臨的問題只是您開始使用的不良分支策略的一個副作用:您正在有效地在 develop 上開發新的開發(即向未來收斂的方向) >生產代碼)直到 當前生產代碼在 master 上。這導致矛盾的要求和問題,因為典型的未來的代碼與當前的代碼不同:

  • the new development destabilizes production - regressions seen after merging develop into master
  • stabilizing the production slows down future development - you need to stabilize develop to make it good enough for merging into master

丟棄 develop 不會幫助(很多) - 你不能解決問題,只是將 develop 特定部分的問題轉移到 master </代碼>。

更好的方法是將產品移動到當前/未來的開發之後,以防止對未來版本的開發產生幹擾,如什麽是你的分支模型?

enter image description here

請註意,我只是指上圖中的發布分支,而不是主幹中發生的事情。

這將如何為你工作:

  • the develop branch dissapears, as you wished, absorbed into master
  • the master branch is your trunk, this is where development happens with no speed restrictions (it's never merged into production).
  • production is/are one or more release branches pulled from a master label/tag considered close enough to production quality (a short list of remaining todo items can be addressed in that branch if needed). These branches can only receive direct hot-fixes and/or cherry-picked fixes from master, they are never merged with master or other branches
  • hotfixes are direct commits into release branches

如果修補程序僅適用於生產版本,而不適用於 master ,則它直接提交到 release 分支。如果它同時適用於它通常首先被提交給 master ,並被櫻桃采摘/雙提交到 release 分支。

現在查看 master (已經超過了當前 release 分支被取消的位置)的內容,您有2個選項:

  • continue with feature branches just like you do today, except they'll be based off master, not develop. Converting them to hot fixes remains possible - you'd just have to rebase them to the corresponding release branch instead of master
  • switch to continuous integration and reap its benefits (can be done at any time going forward), including in a progressive manner - gradually pull fewer and fewer feature branches.

如果你喜歡這種方式,你可以從你現在的位置到達那裏:

  • establish a release naming strategy:
    • you can't have an ongoing release branch with the same name
    • you can't (shouldn't actually) rebase or sync a production release branch
  • pull a releaseX branch from master immediately, following that naming strategy
  • stop commits from going into develop, they'll be soon going straight to master.
  • merge develop into master
  • instruct developers to rebase their workspaces on master instead of develop.
  • open master for commits
  • delete develop if you desire (or leave it permanently locked/read-only for reference)

Well @dan-cornilescu says it well for your particular problem, but the more general case for Trunk-Based Development (mentioned in the Continuous Delivery, Lean Enterprise, and The DevOps Handbook) is made here: https://trunkbaseddevelopment.com/