4

我写了一个节点模块，它使用 git 不时进行一堆提交。考虑到如果将提交分组为一个提交会更好，我想使用“git rebase -i”将它们压缩成一个。

但是压缩只能在交互模式下进行，这意味着我需要手动编辑在调用“git rebase -i”时弹出的编辑器中的行。我想知道是否可以以编程方式执行此过程？因此，例如，当用户调用“保存”函数时，我的模块会进行一堆提交，然后自动将它们压缩在一起。

更新

为了更准确地说明我在做什么，当调用“保存”函数时，它会传递一堆提交以“发布”。然后我的模块将挑选这些提交并将它们放入“发布”分支。这是一个单一的“发布”操作，但它会在“发布”分支上生成一堆提交。我想做的是压缩发布时的提交，所以当我执行“git log”时，我看到的只是“发布版本 1”、“发布版本 2”等，而不是每个发布操作 5 或 10 个提交。

4

1 回答 1

2

在看到您对问题的更新后，以下两个选项之一可能会起作用，具体取决于您的使用情况：

第一种（也是更简单的）情况是您未发布的工作始终是一个提交序列，并且已发布的工作位于同一个分支上，但稍微落后一点：

  • 你有一个unpublished分支和一个published分支。后者包含在前者中（即后面的一些提交）。
  • 保存操作意味着abcdef来自的哈希unpublished现在应该是published.
  • 它执行git checkout published && git merge --ff-only abcdef。
  • 这会导致published快进到该提交。

第二个是可以发布的提交不一定是线性序列。这变得有点复杂，就像您重新排序提交一样，您可能必须解决出现的冲突。我会通过以下方式解决这个问题：

  • 再次假设有unpublished和published分支。
  • 保存操作包含来自unpublished.
  • publish-2013-04-15-001它应该像从当前分支一样创建一个新的临时分支published（新分支的名称在很大程度上无关紧要，只要它是唯一的/新的）。
  • 对应保存的每个哈希执行git cherry-pick <hash>。（如果有多个提交，这就是你可能会遇到冲突的地方，可能需要以某种方式解决它们。）
  • 完成后，检查published分支。
  • 执行git merge --squash -m 'Publish version <n>' publish-2013-04-15-001。
  • （可选）删除临时分支。

由于第二个选项引入了更多复杂性，因此您可能需要考虑其他选项以更轻松地调试已发布的进程：

  • 我应该保留临时分支以进行跟踪/记录吗？
  • 单个提交是否可以在合并的分支上分开（省略--squash）？
  • 如果是这样，您可以通过强制合并提交 ( --no-ff) 来识别保存。

编辑：这是一个使用--no-ff. 每个版本$N执行以下操作：

git checkout -b publish-$N published
# cherry-pick commits
git checkout published && git merge --no-ff publish-$N -m "Publish version $N"

示例 tig 图

于 2013-04-15T21:08:07.087 回答