让我们有一个git master分支,并在某个时候让fork分支发布(release分支称为R1)。有时我需要对它们(master和R1)都进行提交。通常,我在master分支上工作,完成测试后,选择R1,在那里进行测试,然后将它们推入两者。
我想在R1中提交对master分支的引用。这是通过cherry-pick -x完成的。但是,这种方法仅在我推送到master分支,然后从master到R1的情况下才起作用。可以说测试花费了太多时间,我想使master和R1尽可能地保持同步(我希望尽量减少两次推送之间的时间间隔),所以我想同时进行推送。这样,我无法获取引用(cherry-pick中的-x),因为在R1中进行基变时哈希将发生变化(无法使用合并)。 有什么方法可以自动执行此操作,因此我将在R1描述中使用正确的哈希值?像哈希预测一样?
答案 0 :(得分:0)
有什么方法可以自动执行此操作,因此我将在R1描述中使用正确的哈希值?像哈希预测一样?
简短的回答是“否”。
更长的答案仍然是“否”,但是您可能不需要预测哈希值。这里的问题是,您正在从F
复制一些修订提交(我们称为master
)到另一个分支。我们将此称为-x
精心挑选的副本提交Fx
。您还可能最终将修订提交复制到新的修订提交,因为要避免在此工作流程中使用git merge
,因此,如果master
获得了新的提交,则可以使用rebase来选择{ {1}}到新的提交F
中,您将添加到F'
中,现在您想将master
(您挑剔的Fx
副本)替换为F
的精选副本。
因此,您可以这样做。如果您将提交F'
设为F
的基础,请从另一个分支中剥离F'
并重新运行Fx
以将git cherry-pick -x
复制到F'
。您已经知道这些提交是哪些提交,因为您具有原始的哈希ID Fx'
,并通过重选(领取)对其进行樱桃选择会产生F
;并且您在F'
中拥有F
的哈希ID。缺点是,此操作将在 之后Fx
重新复制另一个分支上的所有提交,因为“从另一个分支上的条带Fx
”可能很简单。
(一种避免所有麻烦的替代方法,是将修补程序合并到两个分支中。请参阅How to do a partial merge in git?和链接的博客文章。)