我在這里看到了很多類似的問題，但沒有一個回答我們的具體問題。我的問題實際上是關于合并策略的，但我必須先描述我們的 git 流程。我已經為理想的 Git 作業流閱讀了大量最佳實踐，但沒有發現完全適合我們的需求。所以我們可能使用了一種不理想的方法。
這是流程：
我們有一個master分支，與生產環境保持一致。我們有一個可發布的分支，用于在具有真實資料的預生產環境中測驗發布包。我們有一個穩定的分支用于在穩定的環境中進行測驗。當我們開始處理一個新功能時，我們從master創建一個功能分支。功能完成后，我們通過 pull pequest將其合并到穩定版。這是問題所在；許多功能要么在測驗完成后被取消，要么必須等待未來的發布，所以我們必須從master分支，因為我們不希望這些功能出現在我們的新分支中。出于這個原因，我們也不能合并穩定與可釋放。因此，如果該功能準備好繼續進行，我們會通過另一個拉取請求將功能分支合并為可發布的。現在，由于合并提交，穩定和可發布之間存在不同的提交。在包準備好部署后，我們將可發布與master合并。我的問題來了；當我們從master創建一個新功能分支以開始處理新功能時，它與stable 的提交歷史略有不同。由于這種差異，有時所有檔案更改都會顯示在功能之間的差異中分支和穩定，即使它們的內容相同。
我們正在使用 Bitbucket。我已經考慮在拉取請求中使用 -ff 而不是 --no--ff，但我也不想丟失合并提交。我也考慮過在 Bitbucket 中使用Rebase、merge (rebase merge --no-ff)合并策略，但我不確定它會解決我們沒有干凈的 pull request 的問題。
總而言之，我需要有干凈的拉取請求才能穩定，只需要在該功能分支中完成的更改，而不必犧牲太多。
任何幫助，將不勝感激。
uj5u.com熱心網友回復：
沒有一種適用于所有 Git 分支策略的通用方法，但有涵蓋大多數場景的概括。它們往往屬于以下類別之一：
- 單個長期存在的共享分支（通常為
main或master）。這可以進一步細分為2子類別：A）基于主干開發（TBD），開發人員上的本地副本的所有作業main，和B）的開發者都岔開的main用自己的親身分支機構和合并回main。即使這有很多選項，例如 rebase 然后快進合并，或者 rebase and--no-ff，或者根本沒有 rebase，或者有/沒有拉取請求等，但整體包含的想法是每個人都在作業的單個共享分支。這在 CI/CD 型別交付中很受歡迎。 - 至少一個 Long-Lived Shared Branch，以及一些 Short-Lived一次性集成分支。這是 Git 的維護者使用的，它被稱為“Gitworkflows”。這是我為您推薦的類別；更多詳情如下。
- 單獨的長期共享分支，以便在當前待定版本以及待定版本之后的下一個未來版本上同時進行開發。這個類別是類似于“Git Flow”的策略風格。
- 其他三者的某種組合。
請注意，您的問題與此問題非常相似，答案幾乎是我在您的情況下推薦的答案，但要稍作調整。主要區別在于，在您的情況下，您有 2 個長期存在的分支（master和releasable），并且您可能會受益于使您的stable分支成為master經常重置的一次性分支。（如果您希望與 Gitworkflows 更緊密地對齊，您也可以重命名stable為next。）我發現 1 或 2 周的重置頻率通常適用于next分支。你重置的次數越多越好，因為它更像你合并時會發生的事情master. 但是您不希望它經常讓尚未完成測驗的開發人員感到不安，然后必須重新合并next以在重置后繼續測驗。這將解決您的眼前問題的一個可能的復位頻率將恢復stable到master只要你合并releasable成master。
旁注：在我的公司，我們在同一個 repo 中使用所有 3 類策略，具體取決于專案（因此將我們置于第 4 類）。對于我們的 Git Flow 專案，我們還在next沙盒開發環境中用作“預測驗”，以便在合并到develop. 我們next每周為該專案重置一次。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/371728.html
上一篇：Git2.34.1：在沒有加載組態檔的情況下在bash中提交時出現錯誤“致命：模棱兩可的引數'HEAD'：未知”