针对修补程序和修补程序等发布分支的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

回答

相关问题