在合并存盤庫時，我能夠使用引數成功地將歷史記錄合并到單個存盤庫中，并合并到功能分支（不是主分支）中--allow-unrelated-histories。問題是，我們使用的是 Azure DevOps，所以當我將更改推送到中央存盤庫并完成對我們QA（父）分支的拉取請求時，歷史記錄并沒有遵循。我很確定這是因為我們的合并策略是squash commit.
然后我做了以下事情：
- 在我當地的
QA分支機構中，我做了git merge <feature-branch>，隨后git log并驗證了所有不相關的歷史記錄。 - 然后我做了
git push（我是專案管理員并且能夠繞過分支策略），這是成功的。但是，在 Azure DevOps 中，分支中給定檔案的歷史記錄QA仍然不存在。
沒有從頭開始重做所有事情并確保我禁用squash commit，有沒有一種方法可以在事后合并歷史，當它在我的本地分支上但不在中央倉庫中時？
uj5u.com熱心網友回復：
tl; dr：我認為你所做的確實有效，但無論如何我都會考慮重做。
細節：
問題肯定是由 squash 合并引起的，您后續的常規合并確實達到了預期的效果。在 AzureDevOps 中查看檔案的歷史記錄時，您有不同的視圖，默認為“簡單歷史記錄”。嘗試將其更改為“完整歷史記錄”或“完整歷史記錄（簡化合并）”，我的預感是您會看到額外的提交。您所做的第二次合并實際上對檔案沒有影響，我認為這就是默認視圖不包含它們的原因。
現在，即使這解決了您查看歷史的直接愿望，我還是會考慮解決這個問題。如果我站在你的立場上，我不希望有一個大的壓縮提交，然后是另一個沒有有效更改的合并，永遠留在歷史中。這有點混亂，特別是考慮到某些默認視圖不會包含您所見證的歷史記錄。由于聽起來您現在無論如何都處于重寫模式，因此我會借此機會正確重做合并。請注意，它不必“從頭開始重做所有事情”，因為您所要做的就是將 QA 分支重置到壁球提交之前的位置，強制將其推出，然后使用 PR 重新執行 PR相同的功能分支。請注意，即使該功能分支不再存在，您也可以簡單地從它所在的提交 ID 重新創建它，如果您需要參考它，應該可以在 AzureDevOps 的 PR 歷史記錄中查看它。顯然，僅重做一個 PR 的簡單性假設自您之后沒有其他 PR 觸及 QA 分支。如果還有更多需要重做，您需要決定是否值得重做這些作業。
其他想法：
如果您想跳過 PR，您實際上可能不必重做 PR。你可以考慮做一個 rebase 并結合--ontoand--rebase-merges選項，然后強制推出你重寫的QA分支。（我將決定如何做到這一點作為一個單獨的練習，特別是因為我實際上不建議在這種情況下這樣做。）但是，如果你只有少量的 PR 需要重做，我可能會走那條路，以便 PR 歷史記錄中的提交 ID 與存盤庫中的提交 ID 匹配。另一個選擇，因為你有能力繞過 PR 策略，是重做 PR，然后用覆寫完成它，以防你不想讓其他人參與這個程序。
最后，這是一個非常次要的觀點，但我想在你的一個陳述中提到一個措辭失誤：
在我本地的 QA 分支中，我執行了 git merge ，然后執行了 git log 并驗證了所有不相關的歷史記錄。
實際上，那段歷史是相關的。“無關”一詞意味著歷史中沒有共享提交。當您合并從不同根提交開始的兩個存盤庫時會發生不相關的情況，這就是為什么您必須使用--allow-unrelated-histories將兩個存盤庫合并在一起的選項。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/493534.html
下一篇：為什么我的左邊距不能正常作業？