大家好!一个问题。让我们开始介绍
我在做某种诡计。在它得到优化之前,我正在从这个分支创建另一个分支以继续工作。例如:一个分支被调用CreateFeature- 它是来自该分支的拉取请求master;在此分支被批准合并之前,我将转移到一个新分支以做其他有用的事情。也就是说,在一个分支上CreateFeature,我写git checkout -b NewFeature;
在做了一些工作后NewFeature,该分支机构获得了CreateFeature批准。所以,我切换到它并执行它git rebase -i (squash)- 我将所有提交整合到一个。然后我把它上传到master。
所以,当分支被批准时NewFeature,我需要做同样的事情:重新设置分支master并执行git squash;
我现在也有类似的情况。我正在尝试将提交合并为一个并重新设置为 master,但是重新设置的每一步都会导致无法控制的冲突。git rebase可能是因为我已经建立了一个新分支后进行了清理。
告诉我,是否有任何选项可以强制新分支重写它的来源分支的历史git rebase?之类(now on NewBranch) git pull --force OldBranch的,然后在没有冲突的情况下压缩提交?这很痛苦,有大量的提交,而且很难解决每个提交的冲突
在您的情况下,可能最简单的解决方案是首先将分支移动
NewFeature到基于对 master 的压缩提交。方法是现在您有了在
NewFeature-2中所做的更改NewFeature,但已经使用 squash。然后你可以删除
NewFeature和重命名NewFeature-2,然后甚至变基,甚至合并。在某些时候,我们有这张照片:
我们需要将一系列
m-n提交合并到一个提交中(做一个“squash”),将这个提交(让我们称之为mn)添加到指针master(记住在git程序中, “分支”只是指向提交的浮动指针吗?) , 并继续使用指针feature2,但这样它的“基础”不再是一个提交n,而是一个新的提交mn。让我们开始吧。切换到
master并开始与指针合并
feature1:在这种情况下,不会自动创建提交,这是git程序告诉我们的。如果出现冲突,我们会以通常的方式解决。
一切准备就绪后,提交:
图片现在看起来像这样:
现在我们需要将一系列提交
x-y“重新设置”到新的“基础”。句法:对于我们的示例,它看起来像这样:
我们得到了我们需要的东西:
事实证明,一切都简单得多。
如果我们从 master 分支,我们可以通过
git squash + git rebase master如果我们从某个分支进一步分支,我们这样做:
2)结帐到我们要合并的分支
git reset - - soft hash,提交,合并主要是没有冲突,所以在reset之前,你可以做
git pull master