最近，我們轉向了“Git Flow”方法，我們在其中使用develop、release和main分支。最近，我們main從與最近分支相同的提交中創建了一個release分支。每次我們將一個release分支合并到 中時main，我們都會合并main到develop中，通常在我們首先解決沖突的地方有一個新分支main（因為它們是受保護的分支）。
但是，隨著從release中創建最新的分支，我們在（就在此時）和develop之間存在沖突。解決這些沖突只是一個 0 檔案更改 PR，但我不明白為什么首先會有沖突。我繪制了最近的歷史來嘗試進一步展示這個程序：releasedevelopmain
Git 行程
請注意，所有這些合并都被壓扁
任何幫助將非常感激！！
uj5u.com熱心網友回復：
如果您使用的是標準Git Flow，則在合并到/時永遠不會出現合并沖突。如果確實有沖突，那就是有問題。不應該存在沖突的原因是因為提交出現的唯一兩種方式是來自分支或. 在合并到的情況下，如果發布分支存在，則應立即合并回，如果不存在，則應合并回. 這條路永遠走在前面。releasemainmastermainreleasehotfixhotfixmainmainreleasemaindevelopreleasemain
使用標準的 Git Flow，唯一可能發生沖突的時候是在合并時：
main回到release（修補程式與發布沖突）main回到develop（發布/修補程式與開發沖突）release回到develop（發布與開發沖突）
如果您在合并release到時遇到沖突main，最可能的原因是您有一個修補程式main，之后沒有release立即合并回，跳過此步驟可能很危險，因為如果您將發布分支直接部署到生產環境，您將不會沒有那些修補程式更改。
關于圖中的這段文字：
在某些時候，嘗試將開發合并為主要會導致合并沖突。
我假設您的意思是“合并main到develop”而不是相反，因為實際上并沒有develop直接流入main. main合并到時發生沖突是完全正常的develop，這通常發生在同時修改相同檔案時develop以及release分支后的分支上。這只是一個正常的開發程序，除非您愿意實作代碼凍結。
工藝問題：
請注意，所有這些合并都被壓扁
這似乎不對。這絕對不是 Git Flow 的一部分，通常你永遠不想重寫長期/受保護分支上的提交。這意味著不應壓縮develop, release,hotfix和main/上的提交。master唯一一次將squash與 Git Flow 結合使用可能是在將功能分支合并到developorrelease時，如果您不關心功能分支上的特定提交資訊。
關于此宣告的旁注：
每次我們將 release 分支合并到 main 中，然后我們將 main 合并到 develop中，通常使用一個新的 main 分支，我們首先解決沖突（因為它們是受保護的分支）。
這是一個小問題，但在合并main到. 標準 Git Flow 建議實際上將向下合并到而不是從那里進行，但是，從代碼的角度來看，它并沒有什么不同，并且按照您的方式進行操作在恕我直言，從長遠來看更清潔且效率更高跑步。這是我一直向標準 Git 流程推薦的少數幾個調整之一。developreleasemainreleasedevelopmain
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/435169.html