我怀疑我知道答案,但是想检查一下,因为我希望我错了。
我们在分支机构上做了很多工作,我打算将其与master合并为基础,以便一旦所有内容都准备就绪,便可以保留我们的所有历史记录。我提出了要求请求,其中一位审阅者批准了该请求,并进行了“压缩合并”。无论如何,合并还为时过早,我们还原了master上的更改,但是新目录中保留了master上的历史记录。现在没有“重新合并”的选项(github已变灰)。我试图将分支重新设置为本地母版,但是它失败,并出现错误,指出删除了先前合并文件的提交。
我已经筋疲力尽了。在大师和强行推动下,这种短时间手术是否有办法解决,鉴于拥有回购协议的人数,这不太可能实现?
答案 0 :(得分:2)
在师父的这种短暂手术中是否有出路
从某种意义上说,不是。从所谓的Squash and Merge开始,就从来没有(我之所以这么说是因为Squash and Merge实际上并不是任何形式的合并)。恢复后,您所做的前进;它甚至添加了 more 个提交。 “撤消”实际历史记录的唯一方法是重置。那就是你往后走的方式。对已被推入的材料进行重置的唯一方法是强制推入。
但是,我也不会说所有的一切都丢失了。当然,您的历史很烂,但是那又如何呢?在这一点上,这只是历史上的一个小故障。有一天,它会在时光流逝中迷失。 now 的重要之处在于master
(也就是说,在master
上对任何人进行任何类型的合并之前的最后一次提交)应该处于正确的状态(我的意思是,您所有文件的正确状态)。因此,只需安排该状态,无论其状态如何,然后将其提交到master
上,然后继续即可。
我也想说我不同意这个问题的前提。你说:
我原本打算将此[分支]与master合并,以作为基础,以便一旦所有内容都就位后就可以保留我们的所有历史
错了。 “合并为基础”不会“保留历史”。关于历史的谎言。保留分支历史的方法是合并简单明了的分支。变基不是合并;壁球不是合并; merge 是一个合并。合并是好。它们是保存发生的事情的最干净的方法,同时使未来有可能整齐地发展。 (仅举一个例子,如果您进行了真正的合并,那么,如果您发现合并为时过早,则可以继续处理分支,对其进行修复,然后再次对其进行合并。 ,这不是那么简单。)
答案 1 :(得分:2)
如果我理解正确,则您遇到以下情况:
value
您可以尝试在 squash&merge feature in master
| revert the squash&merge commit
v v
*--*--*--*--*--M--*--*--R--*--*--* <- master
\
*--*--*--s--*--* <- feature
^
the state of the `feature` branch when it was squash&merged
之上重新建立feature
的基础-R
中文件的状态可能与R
开始修改时的文件状态足够接近他们,而这可能会在没有太多冲突的情况下起作用。这很大程度上取决于 other 对feature
所做的修改(上图中的master
)。
如果那样行不通(冲突太多),这是另一种重新组合历史记录的可能性:
*
这将丢弃# 1. starting from commit R :
git checkout -b wip R
# 2. re-revert R :
git revert R
# 3. replay commits s..feature on top of this new commit :
git rebase --onto wip s feature
的历史记录的开头(直到提交feature
)。