我有两个回购。 Origin是Upstream的一个分支。我要做的是从上游分支重放一个特定的提交序列回到我的origin/master。从我一直在阅读，虽然樱桃选择允许范围 - 它没有办法控制你从哪个分支拉动范围所以，我试图使用rebase --onto来做到这一点。这就是我的目标。
我签出了上游分支（git checkout upstream/feature）。这让我陷入无头状态。
然后我从这个无头状态（git checkout -b temp）创建一个临时分支。
现在我想将upstream/feature分支上的所有提交从HEAD重播回标记。我正在执行此命令：git rebase --onto master start_tag^。
看起来这应该重播从start_tag到upstream/feature的头部（现在是分支临时）的所有提交。 rebase运行甚至表示它正在重放输出中的正确提交并完成而没有错误。但是，当我检查master时，新的提交不在那里。看看我的临时分支，看起来它只是重新提交了自己的提交。它们仍然存在，但它们现在有新的提交ID。
知道如何从上游分支到本地分支获取一系列提交吗？我不知道为什么rebase --onto没有在主人身上播放它们。
编辑：那我为什么要这样做？
问题出现了我为什么要这样做。基本上，我已经陷入了兔子洞，我正在尽最大努力来管理我所做的混乱。这是故事。
我们开始使用原始的Joomla网站（称之为repo A）。一切都很好，客户决定他们想要另外3个网站，据说只是一些小的样式变化。所以，我将三个回购（repo B，repo C，repo D）从我原来的repo A中分离出来。
随着时间的推移，对Repo A进行了一些更改，这些更改对于我和其他我想要发送到分叉的其他内容。为了在所有存储库之间共享更改，我创建了一个shared分支。然后在我的下游存储库中，我可以从上游shared拉出repo A分支。
更多时间过去了，这些网站越走越远。我遇到的问题是repo B中使用了repo C中不需要的组件。同样，repo B和repo C等需要一些组件。在我的天真中，我认为如果我可以将单个组件拉入分叉，将更容易管理。在一个梦想世界中，git子模块就像我去的那样，但我不能在Joomla中使用它们，因为它们的结构目录（我不能只跳入一个包含所有组件文件的文件夹） 。我最终决定将我的各个组件分离到他们自己的分支（branch componentY，branch componentZ）。我不得不从repoA master分支出来，因为在repoA shared分支中没有结束的组件分支中需要祖先提交。
在我的下游分支repo B中，我现在从repoA shared分支引入一般更改。我还需要从repoA组件分支中引入新的更改。我遇到的问题是我不能简单地合并到repoA componentZ，因为这会在我创建master分支之前引入repoA componentZ上的所有提交。我标记了第一个componentZ提交，该提交是从我分支为start_tag时开始的。
回到原来的问题，所以我现在正在repo B。我已成功进入repoA shared分支并合并。现在我想进入（合并将是理想的，但我认为它不适用于这种情况）repoA componentZ从该分支的HEAD到我已标记为{的提交的提交{1}}。
所以，是的，非常混乱;但这就是我现在正在使用的。
答案 0 :(得分：2)
你真的不应该在你自己的工作之上从上游仓库中重新开始工作，因为这基本上会覆盖上游仓库的工作，所以他们再也不能接受你提出的任何拉动请求了-requests包含它们被覆盖的提交。
如果您要将本地工作与上游的新更改同步，则需要merge可以使用，或rebase 您自己的工作 < / strong>在上游工作之上。
融合：
git checkout master
git merge upstream/feature
git push origin master
衍合：
git checkout myFeatureBranch
git rebase upstream/feature
git push origin myFeatureBranch
答案 1 :(得分：1)
我怀疑那里的任何人都会像我一样陷入混乱，但是如果它能帮助其他人，我就是这样处理的。我发现修补允许我在分支上进行一系列提交并将其应用到其他地方。绝对不漂亮，但这是我必须做的才能得到我需要的结果。
git checkout upstream/feature git format-patch last_pull_tag^..HEAD git checkout master git am --3way *.patch 如果使用此命令，请确保在应用修补程序后删除这些修补程序，以免日后再应用它们。