Git 工作流程，級聯變基，具有 2 個功能分支

Question

我正在嘗試為特定情況找到一個好的 git 工作流程。

一般情況下工作正常：我有一個主分支，我從中創建一個功能分支。 我會定期將功能重新定位到 master 上，一旦功能准備好，我會在 master 上發出拉取請求。

            master
            v
*---*---*---*
         \
          *--*
             ^
             feature

現在有時，一個大功能需要幾個開發人員。 我們仍然從 master 創建一個 feature 分支，然后從 feature 中創建 feature1 和 feature2。 feature1、feature2 和 feature 之間的工作流程與您在一般情況下使用 feature 和 master 的工作流程相同（對不起，我的 git 繪圖可能有點難看，不習慣這樣做）。

            master      feature2
            v           v
*---*---*---*       *---*
         \         /
          *---*---*
              ^    \
        feature     *---*
                    ^
                    feature1             

在理想情況下，一旦 feature1 和 feature2 完成，我們會將它們 PR/merge 為 feature，然后將 feature rebase 到 master，最后將 feature 的 PR 合並/do 到 master。

但在此之前，我們可能需要將功能重新定位到 master 上，以獲得一些新的更改，或者只是為了不必一次獲得太多的更改。 我們可能有我們修復的沖突（由假設的特征 3 引起，或者可能是因為我們已經從特征 1 合並到特征，即使認為特征 1 還沒有完成）。

Feature1 和 feature2 還沒有完成，我們需要將它們重新定位到 feature。 並且會出現與我們將功能重新定位到 master 時非常相似的沖突。 我最近聽說了git rerere ，但我嘗試了一個非常簡單的示例，我遇到了非常相似的沖突，但並不完全相同，所以我每次都必須解決它們。 我並不完全理解它是如何工作的，所以也許我做錯了什么。

另一種解決方案是不將特征重新定位到主節點上，而是將主節點合並到特征中。 因此，如果在那里解決了沖突，當我將 feature1 重新定位到 feature 時，它們將不再出現。 這污染了特性的歷史，但我想我可以在將特性合並到 master 之前做一個交互式 rebase 來壓縮不需要的合並提交。

所以基本上我的問題是：對於我想要實現的目標，是否有一個好的做法？ 無論如何，我的同事傾向於合並所有內容，但我希望有一些更清潔的東西，並且我可以從頭到尾理解。 我可以繼續變基並避免與git rerere反復發生沖突嗎？ 由於在這種情況下它是公共/共享分支，因此可以重新設置功能嗎？ 我是否應該不關心 state 的功能，直到我決定將它合並到 master 並做一些重構，同時將 master 合並到它中？ 將功能重新定位到 master 而不是將 master 合並到它的價值上太麻煩了嗎？

Answer 1

雖然您通常不會將合並合並到另一個分支，但在這種特定情況下，這將是更實用的選擇（如“將主節點合並到分支”）

重新設置其他分支使用的分支會很快變得棘手，並且rebase設置操作最好保留給其他分支不使用的分支。