我读过关于 git 历史和合并能力的樱桃采摘的不良副作用。然而,我遇到的所有示例都假设分支(从中挑选提交)将继续积极开发-
在我的情况下是不同的。由于我仍在学习 CICD(特别是在 GitLab 中),我通常会采用以下方法:
master
或develop
分支中创建项目框架master
或 develop
)这里的问题是我的游乐场分支充满了诸如“添加日志消息以调试错误 XYZ”或“尝试调整 XYZ”之类的提交。此类提交的数量可能高得惊人(我目前正在处理一个 Django 项目,该分支在管道最终工作之前累积了 200 多个提交!)。在宏伟的计划中,这将在 git 历史中造成混乱,我想避免这种情况(更不用说它表明我在设置 CICD 管道方面的无能 :D)。
我正在考虑使用 git cherry picking 来选择最后一次提交并将其移动到源分支,从而不留下任何痕迹。重要的是要注意,在我的管道设置分支上工作时,源分支根本没有改变。
这会破坏将接收新数据的分支的 git 历史记录吗?
樱桃采摘在这里是错误的选择,不是因为不需要的副作用,而是因为它缺少desired effects.
樱桃采摘大致相当于制作一个特定change的补丁。它很有用,例如,如果您有一个修复文件中拼写错误的提交,在一个分支上进行了一大堆其他尚未准备好的更改。因此,您将拼写错误修复到其他地方的新提交中。
你想要的恰恰相反:你想要包括 all 分支上的更改,无论它们以何种顺序提交;但是您想缩短历史,就好像它们一次都被更改了一样。你想保留最终的state,而不是最近的change。
这被称为压扁提交,可以实现:
git merge --squash
当你合并你的分支到 develop/master/wherevergit rebase -i
并将除第一个提交之外的所有提交设置为“挤压”或“修复”(不同之处在于您是否希望 git 组合所有提交消息)git reset --soft
倒带历史但保持文件的最终状态,然后在新的提交中提交