git-精心挑选的功能提交到新分支，还原的提交，变基无法按预期工作 [英] git - cherry-picked feature commits into new branch, reverted commits, rebase not working as expected

问题描述

我最近不得不从'dev'分支中撤出一项功能，因为该功能被搁置了直到以后.

I recently had to pull a feature out of our 'dev' branch because it's being put on hold until a later date.

为此，我创建了一个分支，该分支的父级位于"dev"上，并且在第一个功能提交之前进行了一次提交(第一个功能提交是与另一个分支的压缩合并).然后，我从中选择了所有功能提交开发人员进入新分支.最后，我对开发人员进行了一次大型的还原提交，以删除那些经过精心挑选的提交.

To do so, I created a branch whose parent is on 'dev' one commit before the first feature commit (the first feature commit was a squashed merge from another branch.) I then cherry-picked all of the feature commits from dev into the new branch. Finally I made one big revert commit on dev to remove those cherry-picked commits.

现在，我想在dev上重新建立新分支，以使其保持最新状态.如果我运行"git rebase dev"，则新分支的头将成为大还原，因此该功能将丢失.

Now I want to rebase the new branch on dev to get it up to date. If I run "git rebase dev", the head of the new branch becomes the big revert, so the feature is lost.

使用"git rebase --strategy = ours dev"时，功能分支中的所有提交都将跳过，并显示消息已应用:0001 ...".

With "git rebase --strategy=ours dev" all the commits in the feature branch are skipped with the message "Already applied: 0001...".

如何将Feature分支重新建立到dev上，以便将对Feature的所有提交都应用到dev的头上?

How can I rebase the feature branch onto dev such that all the commits on the feature are applied to the head of dev?

也许有比我在这里描述的方法更好的方法来进行此过程?

Maybe there's a better way to go about this process than what I've described here?

推荐答案

您可以通过签出功能分支并执行以下操作来解决此问题:

You can fix this by checking out your feature branch and doing:

git rebase --onto dev HEAD~<number of commits you care about> --force-rebase

这会指示git重播您指定的提交范围，并忽略该提交是否发生在对dev进行提交之前的某个时间点.

This instructs git to replay the commit range that you specify and to ignore whether or not the commit occurred at a point in time prior to the commits on dev.

请注意，这将使您拥有类似以下的历史记录:

Note that this will leave you with a history that looks like:

<did some work> -- <reverted all of that work> -- <re-did that work>

可能对您没有什么帮助.这里的其他一些答案详细说明了如何根据您的团队对历史记录重写的容忍度来通过重写它来获得更清晰的历史记录.

which may not be all that useful to you. Some of the other answers here detail how you can get a cleaner history by rewriting it, depending on your team's tolerance for history rewriting.

这篇关于git-精心挑选的功能提交到新分支，还原的提交，变基无法按预期工作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！