以编程方式使用 git rebase -i

Question

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

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

更新

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

Answer 1

查看您对问题的更新后，以下两个选项之一可能有效，具体取决于您的使用情况：

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

• 你有一个unpublished分支和一个published分支。后者包含在前者中（即后面有一定数量的提交）。
• 保存操作意味着abcdef来自的散列unpublished现在应该是 的 HEAD 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"