以编程方式使用git rebase -i

Question

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

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

更新

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

Answer 1

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

---

第一个（也是更简单）的情况是你的未发表的作品总是单一的提交序列，并且已发布的作品在同一个分支上，但稍微落后一点：

• 您有一个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"