GitHub Flow和GitLab Flow有什麼區別？

Question

最近我在GIT中發現了一個工作流程的三個概念：GitFlow，GitHub Flow和GitLab Flow。我讀過關於它的好文章（https://docs.gitlab.com/ee/workflow/gitlab_flow.html），但我不太瞭解GitLab Flow。也許是因爲我不是母語:)

簡而言之。

GitFlow（https://docs.gitlab.com/ee/workflow/gitdashflow.png）。

我們有一個主分支作爲生產分支。此外，我們還有一個開發分支，每個開發人員都合併他的功能。有時我們會創建一個發佈分支來部署我們的功能。如果我們在發佈分支中存在錯誤，請修復它並將更改拖入開發分支。如果我們在生產中遇到嚴重錯誤，請創建新的修補程序分支，修復錯誤並將分支合併到生產（主）並開發分支。

如果我們很少顯示我們的工作結果，這種方法非常好。 （也許每2週一次）。

GitHub Flow（https://docs.gitlab.com/ee/workflow/github_flow.png）。

我們有一個主分支作爲生產分支。我們（作爲開發人員）只能創建分支來添加新功能或修復錯誤並將其與生產（主）分支合併。聽起來很簡單。這種方法適用於生產部門每天部署數次的極端編程。

GitLab Flow（https://docs.gitlab.com/ee/workflow/production_branch.png,https://docs.gitlab.com/ee/workflow/environment_branches.png,https://docs.gitlab.com/ee/workflow/release_branches.png）。

我已經看到像預生產，生產，發佈（穩定）分支和臨時環境，預生產環境和生產環境這樣的新術語。他們之間有什麼關係？

我明白這一點：如果我們需要添加一個新功能，我們會從主分支部署一個預生產分支。當我們完成該功能後，我們從預生產分支部署生產分支。預生產分支是中間階段。然後主分支從生產分支中提取所有更改。

如果我們想要查看每個單獨的功能，該方法很好。我們只需在分支中籤出我們需要和看的東西。

但是，如果我們需要展示我們的工作，我們會盡可能晚地創建一個帶有標籤的發佈分支。如果稍後我們修復主分支中的錯誤，我們需要將它們挑選到最後一個發行版分支。最後，我們發佈了帶有可幫助我們在各個版本之間移動的標籤的分支。

我的視力正確嗎？ 拉和櫻桃採摘有什麼區別？

Answer 1

GitLab Flow建議使用master和feature分支。一旦功能完成，我們將其合併回master分支。該部分看起來與GitHub Flow相同。

然後我的理解是，他們給了我們兩個選擇，如何做到這一點，取決於它是否是SAAS應用程序或移動應用程序（可以釋放到世界）。

如果這是SAAS應用，我們使用環境分支，例如， pre-production和production。當我們準備部署我們的應用程序時，這些分支是在master之外創建的。每個環境有不同的分支允許我們設置CI/CD工具來自動部署對這些分支進行的提交。如果存在嚴重問題，我們將其修復爲feature或master分支，然後將其合併到environment分支。

至於可以發佈到世界的應用程序（例如移動或桌面應用程序），我的理解是他們建議使用release分支而不是環境分支來使用不同的模型。我們仍然在feature分支中完成所有工作，並在完成後將它們合併回master分支。然後，當我們確保master分支足夠穩定時，即我們已經執行了所有測試和錯誤修復後，我們創建release分支併發布我們的軟件。如果出現嚴重問題，我們首先在master分支中修復它，然後櫻桃選擇release分支。

Answer 2

自從這篇文章被提出以來已經過去了一年，但考慮到未來的讀者和事實已經改變了一些，我認爲這值得提神。

GitHub的流量爲originally depicted by Scott Chacon in 2011假設一旦在feature branch審查每一個變化和合併爲master應立即部署到生產環境。雖然這個工作的時候，符合唯一GitHub的流動規律，這是任何在主分支部署，it was quickly discovered，爲了保持master知真實記錄工作的生產代碼實際部署到生產中應發生在feature branch之前合併到master。從feature branch進行部署非常有意義，因爲在任何問題產生的情況下，都可以通過部署master進行即時恢復。請看看GitHub Flow的a short visual introduction。

GitLab流程是對GitHub Flow的擴展，附帶一組guidelines and best practices，旨在進一步標準化流程。除了促進準備部署master分支和功能分支（同GitHub的流量），它引入了另外三種分支：

1. Production branch
2. Environment branches：uat，pre-production，production
3. Release branches：1-5-stable，1-6-stable

我相信上面的名字和例子是自描述的，因此我不會詳細說明furt她的。