rebase-main

name	rebase-main
description	把当前分支上的所有 commit 压成一个,再 rebase 到最新的 origin 默认分支(main/master 自动探测)。**压缩是一次性的**:本 skill 跑完即结束,之后的任何新改动一律新建 commit,不许 amend / reset --soft 再 commit 折进去——用户之前说过 squash 不构成授权,唯一的授权信号是用户重新调用本 skill。当用户要求 squash commit、压缩提交、整理成一个 commit、rebase 到最新 main/master 时使用。

把当前分支压成一个 commit,再 rebase 到最新的 origin 默认分支。

核心规则:压缩只发生在本次调用

授权的边界就是这次调用本身。 skill 在 rebase(或 push)完成的那一刻结束。

之后,本会话里的任何新改动 —— 不管是用户提的新需求、review 意见、还是修自己刚写出的 bug —— 一律 git commit 新建 commit。具体禁止:

• git commit --amend(把新改动折进上一个 commit)
• git reset --soft HEAD~N 之后再 commit
• git rebase -i / git rebase --autosquash / git commit --fixup

"用户之前说过要 squash" 不构成理由。 唯一的授权信号是用户重新调用 /rebase-main —— 那时候照常执行下面的流程,把分支上现有的一切(包括上次压出来的那个 commit 和之后的新 commit)重新压成一个,再 rebase 到最新 base。天然幂等,所以不需要任何"squash 模式"的开关,也不要自己发明一个。

唯一例外:纯改 commit message(工作区干净时的 git commit --amend -m "...")不算把改动折进去,可以做。判据是有没有新的代码改动被并进那个 commit。

这条规则存在的原因:agent 听到一次 "squash" 之后,容易把它当成持续生效的模式,把后续每一次改动都继续折进同一个 commit。那不是用户要的。

0. 前置检查

git rev-parse HEAD              # 记下来!压缩前的 HEAD,出事就是靠它回滚
git branch --show-current
git status --porcelain

• 把压缩前的 HEAD hash 记住,收尾时报告给用户 —— git reset --hard <原HEAD> 能完整恢复,是这次操作唯一的后悔药。
• 当前在默认分支上(main/master)→ 停下来问,不要在主干上压历史。
• 工作区不干净 → 停下来问用户:这些改动是要一起压进去,还是先 stash?不要自作主张 stash 或 discard。

1. 探测目标分支

不要写死 main,仓库可能是 master 或别的: