使用Gerrit進行長時變基

Question

我們的項目是多模塊Maven項目。 該項目依賴於另一個多模塊Maven項目。 poms的關系（無論是聚合還是繼承）都像

parent-super-pom
|---parent-module-1
|---parent-module-2
|---parent-module-3
|---...
|---parent-module-n
|---child-super-pom
    |---child-module-1
    |---child-module-2
    |---child-module-3
    |---child-module-4

parent項目中的所有內容都由一個單獨的團隊管理，我們稱之為framework 。 在一切child項目是由我們的團隊管理，讓我們把它稱為product 。

現在， framework已升級為使用spring-boot以及許多其他重大更改。 我們需要開始開發以升級product以使用framework的最新技術。 升級過程大約需要一個月的時間（包含許多無法編譯的提交），因為要使應用程序正常工作，需要注意很多更改。 同時， product還將在舊的Maven環境中自行開發功能。 解決這種情況的最佳方法是什么？

我們使用Gerrit代碼審查。 更改首先在gerrit上進行，有自動的jenkins作業觸發器可運行基本測試。 僅當構建通過時才能提交更改。 還可以基於一些觸發條件，通過Gerrit注釋來要求構建，例如運行耗時的Web測試，集成測試等。

我的點子

在以下情況下， 用力推是指它必須繞過gerrit，即直接推到分支，而不是重新創建git歷史的實際力推

• 在product創建要升級的功能分支，例如feature/upgrade
• 確保在新環境（包括按需環境）中為此分支設置了臨時配置項作業
• 將更改推送到升級所需的此分支，直到應用程序可以正常運行
• 時不時地基於master分支，以避免在升級結束時發生批量沖突（將需要對feature/upgrade進行強制推送）
• 最后，將所有更改從feature/upgrade推送到master （將需要對master進行強制推送），然后在master配置CI作業以開始使用與新創建的臨時作業類似的配置

這個想法的缺點是強行推動。 我們確保分支機構不會受到這種推動，因為這會使分支機構容易出錯，並且組織中只有少數人可以提交此類提交。 可能是我沒有意識到我可以在此處利用的某些Gerrit功能，或者我的想法是完全錯誤的。 我需要知道處理這種情況的最佳方法是什么。

Answer 1

為什么不設置監視gerrit事件的小型進程，如果將提交推送到refs/for/$your_feature_branch那么它將自動將“ Verified標志設置為+1。 您甚至可以等待Jenkins將“ Verified設置為該分支上的任何值，然后根據該事件再次將“ Verified設置為+1。 這樣，您可以確保能夠獨立於Jenkins失敗的構建而合並提交。