git cherry 从一次性分支中挑选最后一次提交是否会损坏数据将被移动到的分支中的历史记录?

问题描述 投票:0回答:1

我读过关于 git 历史和合并能力的樱桃采摘的不良副作用。然而,我遇到的所有示例都假设分支(从中挑选提交)将继续积极开发-

在我的情况下是不同的。由于我仍在学习 CICD(特别是在 GitLab 中),我通常会采用以下方法:

  1. 根据项目的管理方式,在我的
    master
    develop
    分支中创建项目框架
  2. 检查 CICD 管道设置的新分支
  3. 在该新分支中进行实验,直到管道完全正常运行
  4. 合并回源分支(
    master
    develop
  5. 删除管道的分支

这里的问题是我的游乐场分支充满了诸如“添加日志消息以调试错误 XYZ”或“尝试调整 XYZ”之类的提交。此类提交的数量可能高得惊人(我目前正在处理一个 Django 项目,该分支在管道最终工作之前累积了 200 多个提交!)。在宏伟的计划中,这将在 git 历史中造成混乱,我想避免这种情况(更不用说它表明我在设置 CICD 管道方面的无能 :D)。

我正在考虑使用 git cherry picking 来选择最后一次提交并将其移动到源分支,从而不留下任何痕迹。重要的是要注意,在我的管道设置分支上工作时,源分支根本没有改变。

这会破坏将接收新数据的分支的 git 历史记录吗?

git version-control cherry-pick git-cherry-pick
1个回答
2
投票

樱桃采摘在这里是错误的选择,不是因为不需要的副作用,而是因为它缺少desired effects.

樱桃采摘大致相当于制作一个特定change的补丁。它很有用,例如,如果您有一个修复文件中拼写错误的提交,在一个分支上进行了一大堆其他尚未准备好的更改。因此,您将拼写错误修复到其他地方的新提交中。

你想要的恰恰相反:你想要包括 all 分支上的更改,无论它们以何种顺序提交;但是您想缩短历史,就好像它们一次都被更改了一样。你想保留最终的state,而不是最近的change

这被称为压扁提交,可以实现:

  • 使用
    git merge --squash
    当你合并你的分支到 develop/master/wherever
  • 使用
    git rebase -i
    并将除第一个提交之外的所有提交设置为“挤压”或“修复”(不同之处在于您是否希望 git 组合所有提交消息)
  • 使用
    git reset --soft
    倒带历史但保持文件的最终状态,然后在新的提交中提交
© www.soinside.com 2019 - 2024. All rights reserved.