first-contributions 中的 Git 实战把提交错误的 commit 移动到正确的分支【免费下载链接】first-contributions✨ Help beginners to contribute to open source projects项目地址: https://gitcode.com/gh_mirrors/fi/first-contributions本篇指南基于 first-contributions 仓库的卡纳达语Kannada附加材料文档《commit ಅನ್ನು ಬೇರೆ branch ಗೆ ಸ್ಥಳಾಂತರಿಸುವುದು》moving-a-commit-to-a-different-branch.ka.md展开讲解一个每位开源贡献者都遇到过的经典失误在错误的分支上执行了git commit该如何把 commit 安全地搬到正确的分支。读完后你将掌握两套完整的命令行序列——把最新 commit 移入既有分支、把最新 commit 移入新建分支——并理解git reset --soft、git stash背后的工作机制与边界条件。场景commit 提交到了错误的分支在 first-contributions 这类每个贡献者一条分支的工作流中参见 卡纳达语 README 中的git checkout -b 分支名分支创建流程分支是隔离各自修改的基本单位。因此一旦你在master或main上误提交了本应属于功能分支的修改直接git push就会污染主干。该场景在仓库的英文原版文档 moving-a-commit-to-a-different-branch.md 中也被列为标准 Git 工作流场景之一卡纳达语译版完整继承了两套操作序列下文在此基础上逐条扩充讲解。序列一把最新 commit 移入一个已存在的分支原文档给出的命令序列如下引自 卡纳达语文档注释已补全为中文git reset HEAD~ --soft # 撤销最后一次 commitHEAD 回退一格但保留所有改动工作区与暂存区不变 git stash # 把当前暂存/工作区状态存入 stash 栈 git checkout name-of-the-correct-branch # 切换到正确的分支替换为实际分支名 git stash pop # 取出最近一次 stash 并自动将其从栈中移除 git add . # 将所有改动加入暂存区也可改为逐个文件 git add file git commit -m your message here # 在正确分支上重新提交执行完毕后你的修改就落在了正确的分支上原分支的 HEAD 已回退到 commit 之前。逐条解析为什么这套组合能工作git reset HEAD~ --soft——HEAD~表示当前 HEAD 的前一个 commit--soft是这里的关键它只移动分支指针不动暂存区index和工作区。也就是说 commit 被拆掉了但文件内容原封不动地回到已暂存状态。这与 undoing-a-commit.md 中讲解的git reset家族一致--soft只回退指针、--mixed默认还会清空暂存区、--hard则连工作区一并丢弃。本场景选择--soft正是为了在回退的同时零丢失地保留改动。git stash—— 回退后改动仍留在暂存区而携带未提交改动直接git checkout到其他分支时若目标分支存在同名文件且内容不同Git 会拒绝切换以防覆盖。先git stash把工作目录清场是规避此问题的稳妥做法。stash 的完整机制栈式存储、git stash list、apply与pop的区别、--index恢复暂存状态在仓库文档 stashing-a-file.md 中有系统讲解apply只恢复改动、条目留在栈中pop在恢复的同时删除该条目序列一用的正是后者。git checkout branch→git stash pop→git add .→git commit—— 到达目标分支后stash pop把改动重新应用回来从源码结构看stash 本质是一个保存工作区暂存区两个快照的引用pop相当于把该快照重新合并进当前工作目录因此已暂存状态不一定被保留——这正是随后还需要执行一次git add .或按原文档提示逐文件git add file的原因。最后git commit -m your message here在正确分支上重新固化这次提交。序列二把最新 commit 移入一个全新的分支当正确的分支尚不存在时原文档给出的第二条路线是git branch newbranch # 在当前 HEAD 位置创建新分支 newbranch分支指向包含误提交在内的全部历史 git reset --hard HEAD~# # 将当前分支回退 # 个 commit这些 commit 将从当前分支的历史中消失 git checkout newbranch # 切换到新分支新分支上仍保有这些 commit工作原理是先分叉、再回退git branch newbranch在回退之前执行所以新分支的指针停在了含误提交的位置完整保存了所有 commit随后git reset --hard HEAD~#只移动当前分支的指针把#个 commit 从当前分支的历史中剔除。#为要回退的 commit 数量例如回退 2 个就写HEAD~2回退 1 个就写HEAD~1原文档写作HEAD~#的占位形式resetting-a-branch.md 中的git reset --hard HEAD~2示例展示了同一回退语法。原文档特别强调的警告执行序列二前必须确保没有未提交的修改git reset --hard会丢弃工作区和暂存区中所有未固化的改动且不可恢复。这与 undoing-a-commit.md 的告诫一致——只在你真的确认要抛弃整个本地开发状态时才运行--hard。两套序列的适用前提与安全边界结合仓库文档可以归纳出几条重要的适用前提仅限本地、未推送的 commit。两套序列都改写了本地分支历史。仓库文档明确指出commit 一旦推送到共享远端执行git reset --hard会给仓库中所有人带来问题见 undoing-a-commit.md。若误提交已经 push应改用git revert生成一个反向提交相关方法见 reverting-a-commit.md。序列一面向最近一次提交序列二面向最近若干次提交。序列一的HEAD~固定回退一格需要移动多个连续 commit 时用序列二的HEAD~#参数化形式。序列一全程无数据丢失序列二不可逆。序列一使用--softstash任何一步出错都可以从 stash 栈找回改动git stash list/git stash apply序列二的--hard一旦执行未 commit 的内容即永久丢失。在 first-contributions 贡献流程中的位置。该仓库的贡献流程是 fork → clone → 建分支 → 修改Contributors.md→ commit → push → 提 Pull Request见 卡纳达语 README。误提交通常发生在本地建分支与 commit 阶段此时远端尚未同步正是本文两套序列的理想使用窗口。延伸first-contributions 仓库中的配套场景文档本文讲解的移动 commit只是 first-contributions 附加材料中的 Git 工作流场景之一同目录下的以下文档可作为配套参考均为 git_workflow_scenarios 目录场景文档移动 commit 到另一分支英文原版moving-a-commit-to-a-different-branch.md撤销本地 commitundoing-a-commit.mdstash 机制详解stashing-a-file.md回退分支resetting-a-branch.md回退单个 commitresetting-a-commit.md场景总目录additional-material.md卡纳达语版的其他场景翻译如 amending-a-commit.ka.md、keeping-your-fork-synced-with-this-repo.ka.md收录于 additional-material.ka.md 索引中可与本文互为参照。【免费下载链接】first-contributions✨ Help beginners to contribute to open source projects项目地址: https://gitcode.com/gh_mirrors/fi/first-contributions创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考