針對修補程序和修補程序等發佈分支的Git rebase

在工作中，我們使用develop分支進行日常工作 - 新功能，錯誤修復等。當我們準備發佈時，我們將devleop分支合併到master，tag和release中。針對修補程序和修補程序等發佈分支的Git rebase

如果我們需要做一個需要立即發佈的修補程序，我們創建一個關閉master的分支，應用更改並進行相應合併（包括將master合併回develop）。到目前爲止，我所描述的沒有任何問題。

我剛剛正在研究一個小錯誤修復程序，該錯誤修復程序將包含在下一個版本中。所以創建了我的平常分支develop，做了幾個提交，並提交了一個PR。然後，一位經理希望今天的修復成爲修補程序。好的 - 簡單的說，我只是將我的工作與master重新分配，並打開PR反對主人。但是，運行git rebase master沒有針對主服務器上的當前HEAD提交重放我的工作。相反，git告訴我，一切都是「最新的」。然後我打開PR反對主人，我的PR包含所有新工作從develop分支，不只是我的錯誤修復。

我能夠做一個交互式重新分配和放棄所有不應該在那裏的提交，但這似乎有點乏味和容易出錯。有沒有一種更理智的方式來實現重新分配針對較舊的最新分支的目標？

來源

2017-06-02 Ryan Wheale

你的小分支上有多少次提交？如果只有一些我可能會嘗試「git checkout hotfix; git cherry-pick develop ... my-branch」。 –

幸運的是，當我們在本週早些時候發佈的時候，這只是我不得不放棄的一些提交，但這個問題的關鍵是不需要知道提交或歷史記錄等等。我希望我的工作基於另一個分支，不管它是1次還是100次。 –

相反衍合「反對master」（即「與master作爲上游」每時使用的命令），則需要與上游設置爲develop變基工作--onto master。

git rebase --onto master develop my_fix

請記住，這會創建一個新的未經測試的代碼狀態;由於熱修復被快速追蹤到生產，因此需要特別注意測試它。

來源

2017-06-02 17:56:11

真棒 - 我從未聽說過'--onto'。那正是我所期待的。 –

針對修補程序和修補程序等發佈分支的Git rebase

回答

相關問題