Mercurial工作流程 - 什么時候可以重新定義，何時合並？

Question

我們已經在工作中使用Mercurial幾個月了。 我們已經修改了我們的工作流程一段時間，結果是：

初始快照正在進行分段 ，然后我們將其克隆到我們的中央存儲庫中 ，每個人都在本地克隆。

• 當我們處理feature / bugfix時，我們總是從staging更新到最新的默認值，以便從最新的生產副本開始。
• 然后，我們將功能分支推送到中央存儲庫進行備份，使其可供團隊使用等。
• 我們繼續我們的QA系統並拉出功能分支並將其合並到那里。
• 如果QA在功能上簽收，我們會將其合並到同一台機器上的穩定分支中。
• 然后我們將穩定分支拉到分段，將其合並到那里並進行匯總測試。
• 如果一切順利，我們將所有內容都復制到實時系統中。

這對我們來說已經有一段時間了，但是仍有一些讓我們走的原點 ： “嗯，也許有更好的方式，它不太自然” 。

我們遇到的最大問題是我們的本地計算機上有一個功能分支。

例：

• 我的系統上有分支62_EpicNewFeature。
• 重點組織優先事項，EpicNewFeature停止工作:(
• 6個月后，我終於恢復了EpicNewFeature的工作

此時，該分支遠遠落后於當前默認值。 如果我完成它並嘗試將其合並到QA上，我將會遇到很多沖突（為此你幾乎總是保留QA上的內容。）

我們有時會采取什么措施來緩解這個問題，我們將默認值合並到EpicNewFeature中，以使其“達到速度”。 這簡化了我們在QA上的合並，但它通常仍然是本地合並的一部分。

我已經閱讀了關於變基的內容，這可能有助於使下一次合並成為一個快進因為你（根據我的理解）在中間注入歷史，改變你自己的歷史。

我讀過關於rebase的大多數地方警告你，如果你已經推動了你的分支，你就不要這樣做，如果有人可能已經取消了你的修改，那絕對不會。 你怎么能確定這一點？ 我們經常推送到中央存儲庫進行備份，我們通常只需要提取所有內容。

您是否看到了有助於我們改進當前工作流程的內容？ 變形會更經常幫助我們嗎？

Answer 1

我想你誤會了墊底呢。 它的工作原理是簡單地合並到存儲庫的頂端，然后切掉原始鏈接。 這與采取“差異”並將其應用於提示幾乎相同。

你仍然會得到你想要避免的所有相同的合並沖突。

通常，處理這些沖突的最簡單方法是零碎的。 不要試圖一次性合並到提示。