GitHub流程和版本

Question

我們對git一般來說比較陌生。我們已經使用了大約6個月，並使用了GitHub和BitBucket。我們嘗試儘可能多地學習使用GitBash，這樣我們就可以獲得git的核心。

我們正處於我們真正想要考慮分支策略的階段，因此我一直在進行一些研究。

在我看來，GitFlow對我們的要求過於複雜。我們總共可能參與20個不同的項目，每個項目每兩個月可能只發布一次。看過GitHub Flow，這似乎是一個非常簡單的選擇，可以滿足我們的需求 - 但它似乎有一個缺陷，我希望人們的意見。

主分支中的任何內容都是可部署的。我們部署到UAT/QA環境，該環境可能會保留3-4周，具體取決於客戶和/或我們簽署所有內容需要多長時間。同時，其他人可能需要完全不同的工作。在這個階段，根據Github Flow的流程，如果該用戶從Master獲得了一個分支，他們將包括此時實際上仍在QA環境中的更改。那麼，我是否誤解了GitHub Flow的第一點 - 即主分支中的任何東西都是可部署的 - 這可能只有在代碼已經通過QA等時纔會響起。

如果是這樣的話，不流實際上看起來更像?:

• 以一個分支從主
• 提交分支的變化（僅回支在這個階段）
• 合併分支與一個單獨的分支稱爲「開發」
• 發佈到QA/UAT
• 當發佈批准後，合併分支與主和部署？

我覺得這是特別1點在GitHub的流量是混淆我們 - 我們何時釋放仍處於QA肯定不應該推回大師 - 這將使主分支潛在不穩定，當然也不是什麼目前正在生產中。

Answer 1

根據我在git-flow cheat sheet和Driessen's original model上看到的，你有一些錯誤。

雖然我自己並沒有使用git-flow工作流程，但從我所知道的情況來看，master只有在發佈準備就緒時才合併到，而不是之前。這樣，master總是反映了什麼是產品 - develop是什麼作爲「主要」發展分支從哪個功能分支被拉和合並。因此，一個成功的git-flow工作流程看起來是這樣的（假設所有這些部門的事先存在，除非另有提及）：

1. 從develop
2. 工作的topic用於創建一個特性分支（我們稱之爲topic）一會兒
3. 合併topic回develop
4. ，直到你準備好發佈
5. 創建一個新的分支執行此操作幾次，QA-releaseno，從develop
6. 待辦事項QA/UAT上QA-releaseno，犯的錯誤修正必要的（你也可以合併QA-releaseno回develop多次請你）
7. 當你準備好釋放，合併QA-releaseno到兩個master和develop，標籤上master釋放，並刪除QA-releaseno

此外，你似乎做了什麼是混爲一談git-flow和Chacon's GitHub flow。 GitHub的流動，至少在其最簡單的形式，是這樣的：從master

工作

1. 分拆的新課題分支（這裏稱爲topic）上topic（如果你在這工作了很時間，合併master回到它定期是topic
2. 一個好主意）
3. 待辦事項QA從topic把往外一拉請求（PR），以master
4. 一旦PR被代碼審查，以每個人的satisfcation，合併topic回master
5. 發佈master立即，或者至少是體面的快速

這個工作流程是專爲團隊和組織是在快速發佈週期（每週多次）。質量檢查不在應用程序級別，而是在單個功能，任務或票證的級別。由於發佈週期具有即時（或至少快速）的反饋，因此master將始終反映生產中的內容。