我們的開發團隊多次被迫將 git 存盤庫遷移到新的托管服務（從 GitHub 云遷移到本地 BitBucket，然后遷移到具有不同 URI 的 BitBucket，并很快遷移到本地 GitLab）。
現在對于當前的 SW 版本，可以通過更改子模塊的 URI 來處理子模塊。但是，我們還需要能夠為具有新工具鏈的新客戶構建舊軟體版本，檢查那些舊版本會導致問題，因為舊 URI 仍然存在。
為了能夠使用新的構建配置構建舊的軟體版本，我們在軟體之上有一種“元構建存盤庫”。
但很明顯，舊的軟體版本仍然會有它們過時的子模塊 URI。我們肯定不是第一個遇到這種情況的人。但是，我找不到任何解決問題的良好做法。
我認為解決方案可能是使用“元構建存盤庫”來配置 “注入”（覆寫）已提交的存盤庫 URI。一個缺點是“發布結帳”會“臟”。
- 這是一種可行的方法嗎？
- 有沒有我沒有找到的更好的方法？
我認為 cmakeExternalProject()或依賴項管理（例如使用Conan.io）可能會有所幫助（而不是使用 git 子模塊），但這些功能/工具也可能會受到先前簽入的 URI 的影響（除了那些在“元構建”中處理的回購”）。
我知道有一些選項可以重寫 git 歷史記錄，從而追溯更改所有子模塊 URI，但寧愿避免這種情況，因為我不知道更改提交哈希等所帶來的所有后果。
uj5u.com熱心網友回復：
對于我的專案，我使用子模塊的相對參考。如果所有存盤庫始終位于同一域中，這通常有效。例如，ssh://git@server/proj/repo我將../repo用于同一專案../proj/repo中的子模塊或同一服務器上但在不同專案中的子模塊，而不是。
這僅在存盤庫被移動到服務器到服務器或專案到專案時才有效，但如果在某些情況下單個存盤庫被重命名或在專案之間移動，則這將不起作用。雖然，由于看起來您只是從服務器到服務器重新定位，它可能會起作用。
uj5u.com熱心網友回復：
正如 Jonathon 提到的，看看您是否可以對子模塊使用相對參考是有意義的。如果您需要再次更改您的托管服務提供商，或者您的存盤庫的 URL 發生更改，那么繼續執行此操作將在未來為您提供幫助。
您應該考慮是否可以重寫整個歷史記錄以反映這些更改。你可以看看git filter-repo（https://github.com/newren/git-filter-repo/）和可能的git rebase -pi。
重寫整個歷史是有風險的，并且有很多陷阱，但總體思路是，每次添加子模塊時更改子模塊路徑，假設您繼承了所有子模塊的歷史。
如果有可能已經開始使用相對參考，那將是值得研究的。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/338544.html
標籤：混帐