我可以在GitHub上應用Git-Flow工作流程嗎

Question

我想實現與git-flow中概述的工作流相同的工作流，但要使用GitHub。 但是問題似乎是，當與GitHub合並時（合並，壓縮或變基），新的提交哈希會添加到master中。 這導致永久的“ develop”分支開始考慮其在master后面的1個提交。

有什么方法可以在github上復制此工作流程嗎？ 還是我應該放棄並使用更簡單的github-flow

Answer 1

簡短的回答 ：不要使用Pull Requests合並到master。 而是使用“快進”在本地執行合並，然后推送分支：

git checkout master
git merge --ff-only develop
git push

警告 ：這僅適用develop具有每一個承諾是master了。

長答案：GitHub上的合並通常是通過批准請求請求來完成的 ； 有人創建了一個新的功能分支，通過網站打開了一個拉取請求，然后在拉取請求被批准后進行合並。 批准將在新分支上創建合並提交。 您要避免合並提交。 但是據我所知，這是Github的默認行為，不能被覆蓋。 解決此問題的唯一方法是使用您選擇的工具在本地使用“快進”策略執行合並，然后將更改推送到GitHub存儲庫。

如果要合並的分支是master分支的直接后代，則只能快進。 如果master擁有develop中沒有的任何提交，則您將無法快速前進，並且將創建合並提交。 如果您使用git-flow的技術從master分支“ hotfix”分支，則可能會遇到此問題。

這樣做有好處嗎？ 要看。 您最終將獲得一個更“簡化”的存儲庫，提交次數更少，但是您可能會錯過Pull Requests提供的好處-更好地查看代碼更改（盡管在實踐中，通常在合並功能分支時進行代碼檢查。Pull Requests從develop到master可以感到多余）。

Answer 2

我建議您放棄並開始使用“ platflorm”流程。 我的意思是github（如gitlab，beanstalk或bitbucket）支持它自己的流程。 我建議您開始將master用作development分支（用於下一發行版），並將所有舊的穩定發行版保留在另一個分支中。 例如：

• 分支主管（5.4開發）

• 分支5.3（當前版本）

  • ... 5.3.2
  • ... 5.3.1
  • 在這里您可以標記5.3.0

• 分支4.9（舊發行版的LTS版本）

  • ... 4.9.2
  • ... 4.9.1
  • 在這里您可以標記4.9.0

始終修復發行分支，並在master中添加新功能。 如果主人保持復古的兼容性，那就准備下一個未成年人。 如果master破壞了某些內容，則...增加主要版本。