Git-knife：像改 Excel 一样改 Git 提交历史

{"title_zh":"Git-knife：像改 Excel 一样重写 Git 提交历史","body_zh":"# Git-knife：像改 Excel 一样重写 Git 提交历史\n\nGit 历史通常被当作只能追加的日志：提交之后，开发者依靠 rebase -i、filter-repo 或一串 Git 命令修正信息。Git-knife 提供了另一种交互方式：把提交历史铺成一张表格，挑中一个单元格直接编辑。提交消息、作者和日期都可以调整，正则查找替换还可以一次处理多条提交。\n\n它的价值不在于让 Git 变成普通表格，而在于降低历史整理的操作成本，同时保留 Git 对文件内容的约束。\n\n## 一张表格，几类常见修改\n\nGit-knife 使用 Tauri 构建桌面界面，底层调用系统中的 Git CLI。用户看到的是可编辑的提交记录表，实际修改仍然落在 Git 对象和引用上。常见场景包括：\n\n- 把一批提交消息中的旧项目名替换成新名称；\n- 修正提交作者姓名或邮箱；\n- 统一日期格式，或者调整提交时间线；\n- 在发布前清理临时提交、拼写错误和不一致的前缀。\n\n这里有一个重要边界：修改提交元数据会改变提交对象的 ID。包含这些提交的后续提交也会产生新的 ID，因此重写之后通常需要强制更新远程分支，并提前和协作者沟通。\n\n## 为什么文件内容仍然可以保持不变\n\n一个 Git commit 主要记录三类关系：父提交、作者与提交者等元数据，以及指向文件快照的 tree 对象。只改消息、作者或日期时，Git-knife 可以复用原始 tree 对象，并通过 git commit-tree 创建新的提交对象。\n\n这意味着提交 ID 会变化，但每个提交对应的文件树可以保持一致。这里的“内容没有改变”应理解为文件快照的 tree 对象没有被重新生成或修改，而不是提交历史完全没有变化。审计时仍然应该比较新旧提交的 tree，以及检查新增的提交差异。\n\n可以用下面的命令验证某个提交的文件树是否一致。请把两个占位符替换成重写前后的 commit ID：\n\nbash\nold_commit=OLD_COMMIT_ID\nnew_commit=NEW_COMMIT_ID\n\ntest "$(git show -s --format=%T "$old_commit")" = \\\n "$(git show -s --format=%T "$new_commit")" \\\n && echo "tree unchanged" \\\n || echo "tree changed"\n\n# 查看两个提交之间是否出现文件差异\ngit diff --stat "$old_commit" "$new_commit"\n\n\n如果两个提交的 tree ID 相同，且 git diff 没有输出文件差异，就说明这次调整没有改变该提交快照。若提交包含多个父提交，还需要结合合并提交的语义进行检查，不能只依赖单个命令的结果。\n\n## 正则批量替换的工程化用法\n\n批量替换很适合处理重复的提交消息，例如把 JIRA-123 统一改成 [JIRA-123]。但正则操作的影响范围通常大于一次手工编辑，执行前应先限定分支或复制一份仓库，并确认匹配结果。\n\n一种可复用的准备方式是先用 Git CLI 找出候选提交：\n\nbash\n# 只检查当前分支最近 200 条提交消息\ngit log -n 200 --format='%H%x09%s' | rg 'JIRA-[0-9]+'\n\n# 导出作者和日期，便于修改前后留档\ngit log -n 200 --format='%H%x09%an%x09%ae%x09%aI%x09%s' > commits-before.tsv\n\n\n在 Git-knife 中完成替换后，可以再次导出并检查：\n\nbash\ngit log -n 200 --format='%H%x09%an%x09%ae%x09%aI%x09%s' > commits-after.tsv\n\n# 检查旧字符串是否仍存在\nif rg -n 'OldProjectName' commits-after.tsv; then\n echo "old text remains"\n exit 1\nfi\n\n\n上面的命令只是验证辅助工具，实际的提交重写由 Git-knife 的界面和 Git CLI 完成。生产仓库中不要把未经审阅的正则直接作用于所有分支。\n\n## 使用前后的检查清单\n\n可以按这个顺序执行一次历史整理：\n\n1. 创建临时分支或备份引用，并确认工作区没有未提交改动。\n2. 记录待修改范围、旧分支头和关键提交的 tree ID。\n3. 在表格中编辑单个单元格，或使用正则查找替换。\n4. 检查提交数量、父子关系、作者信息和提交消息。\n5. 用 git diff、tree ID 和必要的测试确认文件内容没有意外变化。\n6. 在团队约定的窗口内推送重写后的分支，使用 --force-with-lease 而不是无条件的 --force。\n\nbash\n# 推送前确认远程分支没有被别人推进\ngit fetch origin\ngit push --force-with-lease origin HEAD:main\n\n\n这类工具适合个人分支、发布前整理和明确授权的历史修正。对于已经被多个团队依赖的公共分支，修改提交 ID 的协作成本可能高于收益。此时更稳妥的选择通常是追加一个修正提交，或者保留原分支并建立新的清理分支。\n\n## 结语：把历史重写当作一次迁移\n\nGit-knife 让提交历史编辑更接近表格操作，但它没有消除 Git 重写历史的基本风险：commit ID 会改变，远程引用需要协调，错误的批量规则可能覆盖过大的范围。它真正降低的是操作门槛。\n\n采用前应明确三件事：要改哪些元数据、文件 tree 是否必须保持一致、谁会受到分支重写影响。边界清楚、备份完整、验证充分时，Git-knife 可以成为整理提交历史的实用桌面工具。","title_en":"Git-knife: Edit Git Commit History Like a Spreadsheet","body_en":"# Git-knife: Edit Git Commit History Like a Spreadsheet\n\nGit history is usually treated as an append-only log. When a commit message, author, or timestamp needs correction, developers reach for interactive rebase or a chain of Git commands. Git-knife offers a more direct interaction model: it presents commits as a table, so individual cells can be edited in place. Regular-expression search and replace can apply the same correction to many commits.\n\nThe useful idea is not turning Git into a spreadsheet. It is reducing the friction of history cleanup while keeping the file snapshots under Git's control.\n\n## A table for common metadata edits\n\nGit-knife is built with Tauri and uses the system Git CLI underneath. The desktop interface exposes an editable commit table, while the resulting objects and references remain Git objects and refs. Typical tasks include:\n\n- replacing an old project name across a group of commit messages;\n- correcting an author name or email address;\n- normalizing commit dates;\n- cleaning temporary commits, typos, and inconsistent message prefixes before a release.\n\nThere is an important boundary: changing commit metadata changes the commit ID. Descendant commits also receive new IDs, so a rewritten branch normally requires a coordinated force push. Anyone consuming that branch should be informed before the rewrite.\n\n## How file content can remain unchanged\n\nA Git commit records relationships including its parent commit, author and committer metadata, and a pointer to a tree object representing the file snapshot. When only metadata changes, Git-knife can reuse the original tree object and create replacement commits through git commit-tree.\n\nThe commit IDs therefore change, while the trees associated with the commits can remain identical. “The content was not changed” should be read precisely: the file-snapshot tree was not regenerated or modified. The history itself did change. Audits should compare old and new tree IDs and inspect the resulting diffs.\n\nThe following command checks whether two commit snapshots have the same tree. Replace the placeholders with the old and new commit IDs:\n\nbash\nold_commit=OLD_COMMIT_ID\nnew_commit=NEW_COMMIT_ID\n\ntest "$(git show -s --format=%T "$old_commit")" = \\\n "$(git show -s --format=%T "$new_commit")" \\\n && echo "tree unchanged" \\\n || echo "tree changed"\n\n# Check for file differences between the commits\ngit diff --stat "$old_commit" "$new_commit"\n\n\nIf the tree IDs match and git diff reports no file changes, that commit's snapshot is unchanged. Merge commits require extra care because their multiple parents affect the meaning of the comparison.\n\n## A disciplined workflow for regex replacement\n\nBatch replacement is useful for repetitive messages, such as changing JIRA-123 into [JIRA-123]. It also has a wider blast radius than a one-cell edit. Before applying a pattern, work on a disposable branch or backup reference and inspect the candidate commits.\n\nUse Git to produce an audit file before editing:\n\nbash\n# Inspect messages from the latest 200 commits on the current branch\ngit log -n 200 --format='%H%x09%s' | rg 'JIRA-[0-9]+'\n\n# Keep author, email, date, and subject for a before/after audit\ngit log -n 200 --format='%H%x09%an%x09%ae%x09%aI%x09%s' > commits-before.tsv\n\n\nAfter the replacement in Git-knife, export the same view again:\n\nbash\ngit log -n 200 --format='%H%x09%an%x09%ae%x09%aI%x09%s' > commits-after.tsv\n\n# Fail the check if the old text is still present\nif rg -n 'OldProjectName' commits-after.tsv; then\n echo "old text remains"\n exit 1\nfi\n\n\nThese commands are verification helpers; Git-knife performs the rewrite through its interface and the Git CLI. In a production repository, do not apply an unreviewed regular expression to every branch.\n\n## A practical adoption checklist\n\nA reliable cleanup run can follow this sequence:\n\n1. Create a temporary branch or backup ref, and confirm that the worktree is clean.\n2. Record the target range, the old branch tip, and tree IDs for important commits.\n3. Edit individual cells or run a narrowly scoped regex replacement.\n4. Review commit counts, parent relationships, authors, dates, and messages.\n5. Use git diff, tree IDs, and the relevant test suite to detect accidental file changes.\n6. Push the rewritten branch during an agreed maintenance window with --force-with-lease, not an unconditional --force.\n\nbash\n# Make sure the remote branch has not advanced unexpectedly\ngit fetch origin\ngit push --force-with-lease origin HEAD:main\n\n\nGit-knife fits personal branches, release preparation, and explicitly authorized history corrections. For a shared branch consumed by many teams, the coordination cost of changing commit IDs may exceed the benefit. An additional corrective commit, or a new cleaned branch that preserves the original, may be the better operational choice.\n\n## Treat history rewriting as a migration\n\nGit-knife makes commit editing feel more approachable, but it does not remove the fundamental risks of rewriting Git history: commit IDs change, remote references require coordination, and an overly broad batch rule can affect more commits than intended. What it lowers is the operational barrier.\n\nBefore adopting it for a task, answer three questions: which metadata must change, must every file tree remain identical, and who depends on the branch being rewritten? With a backup, a bounded scope, and explicit verification, Git-knife can be a practical desktop tool for maintaining readable Git history.","seo_description_en":"Git-knife edits Git commit metadata in a spreadsheet-like UI while reusing tree objects. Learn workflows, verification commands, and rewrite risks."}