拉取請求顯示在 azure devops 中變基/合並到另一個分支后的舊提交

Question

我們正在嘗試調整 Skullcandy git 流程 - 鏈接

簡而言之，流程是：

1. 功能分支從主分支重新分支
2. 完成該功能的工作后，代碼被重新定位/合並到 QA 分支，如果需要可以對其進行額外測試（在此處創建拉取請求並完成代碼審查）
3. 測試完成后，我們使用另一個拉取請求將功能分支重新定位/合並到主分支

現在我們在使用這種方法的合並和變基方面都遇到了問題。

變基方法：

1. 我們為 QA 和 master 創建 PR（1 個額外提交）
2. 我們使用 rebase fast-forward 完成 PR 到 QA
3. 在 PR 到 QA 完成后，突然 PR 到 master 可以顯示以前不存在的其他提交。 如果我要從原點刪除分支並再次從本地存儲庫推送它並創建新的 PR 以掌握它，它會再次正確顯示 1 個額外的提交

我不確定為什么會這樣。 似乎特性分支的提交歷史被重寫了。 我也不確定這種方法是否可行，因為 rebase 可以創建新的提交 SHA，因此它們可以顯示為更改。

合並方法：

1. 我們為 QA 和 master 創建 PR（1 個額外提交）
2. 我們使用合並完成 PR 到 QA 並掌握
3. 這里發生的問題是，由於在我們再次從 master 重新分支以獲取新功能並為 QA 創建新 PR 之后，merge 創建了一個額外的 Merge 提交，因此它將來自 master 的 Merge 提交顯示為更改。 它還在代碼審查窗格中顯示了在該合並提交中所做的所有更改，這是有問題的。

我猜這個問題的發生是因為合並提交的 SHA 在 QA 和 master 分支上是不同的？

概括

你能幫我理解為什么 rebase 會這樣嗎？

對於我們如何改善我們的流程有什么建議嗎？

我們更喜歡只有主流程，但為此我們需要自動生成的測試環境來進行自動化測試，而我們還沒有:)

Answer 1

我只是在為此尋找答案，並找到了這個 Microsoft 回復。

他們聲稱這是一項功能 - 而不是錯誤。