整理提交并发布 v1.0.0
功能能运行，并不代表历史已经适合交付。本节会把一个修正提交自动折叠进功能提交，从另一条分支拣选文字修复，再用带说明的标签发布 v1.0.0。
什么样的提交容易维护
一个好提交通常满足三点：
- 只完成一件可说明的事；
- 仓库在这次提交后仍处于可检查状态；
- 提交信息能说明动作和对象。
常见前缀不是 Git 强制语法，但能帮助团队快速浏览：
不要为了符合前缀把几个无关修改塞进一条提交。内容边界比前缀更重要。
用 fixup 标记修正提交
从主分支创建筛选功能：
bash
git switch -c feature/filter
printf '\n## 筛选\n\n可按负责人查看任务。\n' >> README.md
git add README.md
git commit -m "feat: document task filters"随后发现任务清单也应增加一项：
bash
printf '\n- [ ] 按负责人筛选\n' >> tasks.md
git add tasks.md
git commit --fixup HEAD--fixup HEAD 会创建一条指向上一提交的修正提交。查看分支新增历史：
bash
git log --oneline main..HEAD结果示例：
text
1b35128 fixup! feat: document task filters
2000136 feat: document task filters这两条记录表达的是同一个功能，分享前可以折叠。
用交互式变基自动折叠
执行：
bash
git rebase -i --autosquash main编辑器会打开一份计划，--autosquash 已经把 fixup! 提交放到目标提交后，并把动作改成 fixup。确认顺序后保存并关闭编辑器。
结果示例：
text
Successfully rebased and updated refs/heads/feature/filter.再次查看：
bash
git log --oneline main..HEAD结果只剩一条：
text
b9ce389 feat: document task filters新的提交 ID 和原来不同，因为变基创建了新提交。这也是不能随意变基公共分支的原因。
只整理自己尚未分享的提交。别人已经基于某些提交继续工作时，变基会让双方看到两套不同 ID 的历史，后续同步会变复杂。
如果变基过程中需要退出：
bash
git rebase --abort解决冲突后继续：
bash
git add 已解决的文件
git rebase --continue用 cherry-pick 拣选单个修复
另一个分支只修正了 README 的一句话：
bash
git switch main
git switch -c hotfix/wording把 README 开头的描述改为：
text
用 Git 清楚地管理团队任务。提交后记下 ID：
bash
git add README.md
git commit -m "docs: clarify project description"
git log --oneline -1切回功能分支，只取这一次修改：
bash
git switch feature/filter
git cherry-pick <hotfix-id>结果示例：
text
[feature/filter 0631382] docs: clarify project description
1 file changed, 1 insertion(+), 1 deletion(-)cherry-pick 读取指定提交的变化，在当前分支创建一条新的提交。内容相同，但提交 ID 和原提交不同。
它适合取一个明确的修复，不适合长期用来同步整条分支。整合完整功能时仍应使用 merge 或经过团队约定的 rebase 流程。
合并功能并创建标签
功能分支已经整理好，主分支没有额外前进，可以快进合并：
bash
git switch main
git merge --ff-only feature/filter--ff-only 保证只移动 main 指针。如果历史已经分叉，命令会拒绝，提醒你重新决定采用合并提交还是变基。
创建带说明的版本标签：
bash
git tag -a v1.0.0 -m "团队任务板 1.0.0"
git tag -n结果：
text
v1.0.0 团队任务板 1.0.0普通分支会随新提交移动，标签通常固定指向发布时的提交。带注释标签还保存创建者、时间和说明，适合正式发布。
推送主分支和标签：
bash
git push origin main
git push origin --tags也可以合并为：
bash
git push origin main --tags检查结果：
bash
git log --oneline --decorate -5结果示例：
text
0631382 (HEAD -> main, tag: v1.0.0, origin/main) docs: clarify project description
b9ce389 feat: document task filters
427a9c7 Revert "chore: add temporary debug switch"
e67b83e chore: add temporary debug switch
bc6bde7 merge: resolve task owner conflict清理短期分支
bash
git branch -d feature/filter
git branch -D hotfix/wording功能分支已快进合入，可以安全使用 -d。hotfix/wording 的变化通过 cherry-pick 生成了新提交，原提交并不在 main 的祖先链上，所以 Git 不认为它“已合并”。确认 README 修复已存在后，才明确使用 -D 删除原分支。
发布前检查
执行项目测试或检查脚本，确认发布提交能正常工作。
用 git status --short 确认没有未提交内容，用 git log 审查即将发布的历史。
创建带注释标签，再用 git show v1.0.0 检查标签和目标提交。
推送分支与标签，最后确认远程跟踪分支和标签都在预期提交上。
1
git commit --fixup HEAD 创建的提交最适合在什么时候折叠？
2
cherry-pick 会把指定提交的变化应用到当前分支，并创建一条新的提交。