first-contributions 实战用 Git 将误提交的 Commit 移动到正确分支软重置 Stash 分支指针操作【免费下载链接】first-contributions✨ Help beginners to contribute to open source projects项目地址: https://gitcode.com/gh_mirrors/fi/first-contributions本指南以 first-contributions 仓库 docs/additional-material/git_workflow_scenarios/moving-a-commit-to-a-different-branch.md 及其 斯洛文尼亚语译文 为主体完整讲解两种最常见的提交进错分支修复方案一是把最近一次提交搬到已有分支二是把最近若干次提交整体迁到一个全新分支。读完本文你将掌握git reset、git stash、git checkout与分支指针的配合用法并了解每条命令背后的行为边界从而在任何仓库中安全、无损地纠正分支错误。一、问题场景提交进了错误分支怎么办在协作开发中分支是用来隔离特性的核心手段参见仓库中的 分支使用指南。但实际操作中很容易发生这样的失误你在某个分支上完成了修改并执行了git commit随后才发现——这个提交并不应该出现在当前分支上而应该属于另一个分支。斯洛文尼亚语版教程开篇即点明了这一场景原文档第 1-2 行Kaj storiti, če izvedeš commit svojih sprememb, in potem ugotoviš da si izvedel commit v napačni veji?如果你提交了自己的更改然后发现自己提交到了错误的分支该怎么办好消息是只要提交尚未被推送到共享远端或者你愿意承担改写历史的风险Git 提供了多条可逆路径来纠正这一错误。教程给出了两种典型做法分别面向目标分支已存在和需要新建分支两种情形。二、方案一把最近一次提交移动到已存在的分支当你的目标分支已经存在例如name-of-the-correct-branch时核心思路是先撤销提交但保留更改把更改暂存起来切换分支再在新分支上重新提交。完整命令序列如下斯洛文尼亚语原文档第 4-15 行# 1. 撤销最近一次提交但保留更改 git reset HEAD~ --soft # 2. 把当前工作区与暂存区状态记录进 stash git stash # 3. 切换到正确的分支 git checkout name-of-the-correct-branch # 4. 恢复 stash 中保存的状态 git stash pop # 5. 重新暂存也可按需 add 单个文件 git add . # 6. 在新分支上重新提交 git commit -m your message here执行完这六步后你的更改就已经落在正确分支上了。下面逐条拆解每个命令的行为以及仓库内配套文档可以提供的佐证。2.1git reset HEAD~ --soft撤销提交但不丢改动git reset是把仓库状态回退到某个提交的命令。仓库的 reset 说明文档指出它与git revert的核心区别在于reset 会取消暂存并把更改带回工作目录而 revert 是从远端移除提交。--soft模式进一步意味着回退提交指针但暂存区与工作目录中的改动全部保留这正是撤销提交而不丢任何成果所需的模式。其中HEAD~表示当前分支的最近一次提交HEAD~1的简写。如果你想回退更多步可写作HEAD~2、HEAD~3等配合 check-commit-log 文档 中的git log --oneline可以先用提交哈希确认要回退到哪一步例如git reset commithash --soft。2.2git stash/git stash pop跨分支搬运未提交的更改撤销提交后你的更改仍停留在工作区。此时直接git checkout切换分支是不安全的——如果目标分支与当前分支对同一文件有不同的版本切换可能受阻或引发混乱。因此教程先执行git stash把状态记录到一个临时的存储栈中让工作目录变干净随后即可自由切换分支。仓库的 stashing-a-file 指南详细演示了这一机制git stash输出形如Saved working directory and index state WIP on master: ...此后git status会显示工作目录干净nothing to commit, working directory clean多个 stash 以栈的形式存放可用git stash list查看如stash{0}、stash{1}git stash pop等价于取出最近一次 stash 并应用然后从栈中删除与git stash apply仅应用、不删除不同若想同时恢复暂存状态可用git stash apply --index。在教程的流程里git stash与git stash pop配对使用达到把旧分支上的改动原封不动搬到新分支的效果。2.3git checkout切换分支git checkout name-of-the-correct-branch将 HEAD 切换到目标分支。此时因为改动已被 stash工作区是干净的切换不会遇到冲突阻碍。更多分支创建与切换命令如git checkout -b可参考 分支使用指南。2.4git add .与git commit -m在新分支上重新提交git stash pop恢复改动后需要重新暂存并提交。教程给出两种粒度git add .暂存当前目录下所有改动适合整体迁移逐个git add file按文件精确暂存适合只想把部分文件提交到新分支的情况undoing-a-commit 文档 中也演示了用git reset file把单个文件移出暂存区、再分别提交的做法。最后用git commit -m your message here在新分支上留下一个全新的提交。注意由于经过了撤销 重做新提交的哈希与旧提交不同这是正常现象。三、方案二把最近几个提交移动到新建分支第二种场景是当前分支如master上积累了一连串属于某个新特性的提交你需要把它们整体搬到一个全新的分支同时让master回退到这些提交之前的状态。教程给出的三步方案利用了一个关键事实新建分支时新分支会完整继承当前分支的全部提交历史斯洛文尼亚语原文档第 18-22 行# 1. 在当前提交处创建一个新分支它拥有当前分支的全部提交 git branch newbranch # 2. 把当前分支master硬回退 # 个提交这些提交将从 master 上消失 git reset --hard HEAD~# # 3. 切换到新分支它会保留刚才消失的那几个提交 git checkout newbranch3.1 为什么先建分支再重置能保住提交Git 的分支本质上只是指向某个提交的指针可参见 分支使用指南 中对分支即指向提交的指针的说明。执行git branch newbranch时newbranch指向当前HEAD所在的提交此时无论之后master指针如何移动这些提交仍然被newbranch引用不会丢失。随后git reset --hard HEAD~#把master指针向后移动#个提交#代表要移除的提交数量。关于--hard的语义undoing-a-commit 文档 与 resetting-a-branch 文档 都做了强调--hard不仅移动分支指针还会同时丢弃工作目录与暂存区中的所有改动。3.2 三个需要牢记的风险点原文档在方案二末尾用大写强调了最重要的警告原文档第 24 行Pomembno: Vse spremembe, ki niso bile commit-ane, bodo IZGUBLJENE!重要任何未提交的更改都将丢失结合仓库配套文档方案二还有三处必须注意未提交的改动会丢--hard会清空工作区任何未git add、未git commit的修改都会被永久丢弃被移除的提交不再存在于mastergit reset --hard HEAD~#后这#个提交只保留在newbranch上除非newbranch也被删除不要对已推送的共享分支执行--hard重置undoing-a-commit 文档 明确指出如果提交已经推送到共享仓库git reset --hard会给仓库中的所有人带来问题——改写已公开的历史需要git push --force之类的额外手段风险很高。因此本方案只适用于尚未推送的本地提交。四、两种方案对比与选型建议维度方案一搬到已有分支方案二搬到新建分支适用场景目标分支已存在需要把一批提交独立成新分支处理的提交数最近 1 个可扩展为多个最近#个是否用 stash是保护未提交改动否是否用--hard否用--soft保留改动是移动 master 指针并清空工作区未提交改动被 stash 保护会被丢弃对历史的影响重新生成一个新提交提交哈希不变只是换了归属分支选型建议如果你只想搬运最近一次提交、且未提交的改动还要保留选方案一。它的核心是软重置 stash 保护全程不丢任何内容如果你想把最近若干次提交整体拆到一个新分支常见于在 master 上不小心连续提交了一个新功能选方案二。它利用分支指针实现零拷贝迁移提交哈希保持原样如果搬移之后还想微调提交信息或把多个提交合并成一个可进一步参考仓库的 amending-a-commit 指南 与 squashing-commits 指南。五、安全执行清单综合上述两个方案与仓库配套文档执行移动提交操作前请按此清单自检先看提交历史用git log --oneline参考 check-commit-log 指南确认要移动的提交及数量确认改动都已被提交或已 stash任何未提交的改动在--hard场景下会永久丢失确认目标分支与#数量无误HEAD~#多写一个数字就会多回退一个提交确认提交未被推送到共享远端已推送的提交应改用git revert见 reverting-a-commit 指南或谨慎评估强制推送的后果全程不要中途手动删除 stash方案一中 stash 是未提交改动的唯一副本误删后可用git stash list检查、git stash show -p stash{0} | git apply -R反向撤销已应用的 stash详见 stashing-a-file 指南。六、小结与延伸阅读提交进错分支是 Git 初学者最常遇到的失误之一但修复手段并不复杂方案一用reset --soft与stash实现无损搬运方案二用建分支 硬重置实现整批迁移。二者都以分支是提交的指针这一基本模型为根基理解这一点后任何涉及分支重排的操作都能举一反三。本仓库还提供了成体系的 Git 工作流场景文档可作为进一步学习入口英文原版Moving a commit to a different branch中文版移动提交到不同的分支重置提交 Reset a commit撤销本地提交 Undo local commitsStash 临时保存 Stashing为什么使用分支保持 fork 与上游同步【免费下载链接】first-contributions✨ Help beginners to contribute to open source projects项目地址: https://gitcode.com/gh_mirrors/fi/first-contributions创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
first-contributions 实战用 Git 将误提交的 Commit 移动到正确分支软重置 Stash 分支指针操作【免费下载链接】first-contributions✨ Help beginners to contribute to open source projects项目地址: https://gitcode.com/gh_mirrors/fi/first-contributions本指南以 first-contributions 仓库 docs/additional-material/git_workflow_scenarios/moving-a-commit-to-a-different-branch.md 及其 斯洛文尼亚语译文 为主体完整讲解两种最常见的提交进错分支修复方案一是把最近一次提交搬到已有分支二是把最近若干次提交整体迁到一个全新分支。读完本文你将掌握git reset、git stash、git checkout与分支指针的配合用法并了解每条命令背后的行为边界从而在任何仓库中安全、无损地纠正分支错误。一、问题场景提交进了错误分支怎么办在协作开发中分支是用来隔离特性的核心手段参见仓库中的 分支使用指南。但实际操作中很容易发生这样的失误你在某个分支上完成了修改并执行了git commit随后才发现——这个提交并不应该出现在当前分支上而应该属于另一个分支。斯洛文尼亚语版教程开篇即点明了这一场景原文档第 1-2 行Kaj storiti, če izvedeš commit svojih sprememb, in potem ugotoviš da si izvedel commit v napačni veji?如果你提交了自己的更改然后发现自己提交到了错误的分支该怎么办好消息是只要提交尚未被推送到共享远端或者你愿意承担改写历史的风险Git 提供了多条可逆路径来纠正这一错误。教程给出了两种典型做法分别面向目标分支已存在和需要新建分支两种情形。二、方案一把最近一次提交移动到已存在的分支当你的目标分支已经存在例如name-of-the-correct-branch时核心思路是先撤销提交但保留更改把更改暂存起来切换分支再在新分支上重新提交。完整命令序列如下斯洛文尼亚语原文档第 4-15 行# 1. 撤销最近一次提交但保留更改 git reset HEAD~ --soft # 2. 把当前工作区与暂存区状态记录进 stash git stash # 3. 切换到正确的分支 git checkout name-of-the-correct-branch # 4. 恢复 stash 中保存的状态 git stash pop # 5. 重新暂存也可按需 add 单个文件 git add . # 6. 在新分支上重新提交 git commit -m your message here执行完这六步后你的更改就已经落在正确分支上了。下面逐条拆解每个命令的行为以及仓库内配套文档可以提供的佐证。2.1git reset HEAD~ --soft撤销提交但不丢改动git reset是把仓库状态回退到某个提交的命令。仓库的 reset 说明文档指出它与git revert的核心区别在于reset 会取消暂存并把更改带回工作目录而 revert 是从远端移除提交。--soft模式进一步意味着回退提交指针但暂存区与工作目录中的改动全部保留这正是撤销提交而不丢任何成果所需的模式。其中HEAD~表示当前分支的最近一次提交HEAD~1的简写。如果你想回退更多步可写作HEAD~2、HEAD~3等配合 check-commit-log 文档 中的git log --oneline可以先用提交哈希确认要回退到哪一步例如git reset commithash --soft。2.2git stash/git stash pop跨分支搬运未提交的更改撤销提交后你的更改仍停留在工作区。此时直接git checkout切换分支是不安全的——如果目标分支与当前分支对同一文件有不同的版本切换可能受阻或引发混乱。因此教程先执行git stash把状态记录到一个临时的存储栈中让工作目录变干净随后即可自由切换分支。仓库的 stashing-a-file 指南详细演示了这一机制git stash输出形如Saved working directory and index state WIP on master: ...此后git status会显示工作目录干净nothing to commit, working directory clean多个 stash 以栈的形式存放可用git stash list查看如stash{0}、stash{1}git stash pop等价于取出最近一次 stash 并应用然后从栈中删除与git stash apply仅应用、不删除不同若想同时恢复暂存状态可用git stash apply --index。在教程的流程里git stash与git stash pop配对使用达到把旧分支上的改动原封不动搬到新分支的效果。2.3git checkout切换分支git checkout name-of-the-correct-branch将 HEAD 切换到目标分支。此时因为改动已被 stash工作区是干净的切换不会遇到冲突阻碍。更多分支创建与切换命令如git checkout -b可参考 分支使用指南。2.4git add .与git commit -m在新分支上重新提交git stash pop恢复改动后需要重新暂存并提交。教程给出两种粒度git add .暂存当前目录下所有改动适合整体迁移逐个git add file按文件精确暂存适合只想把部分文件提交到新分支的情况undoing-a-commit 文档 中也演示了用git reset file把单个文件移出暂存区、再分别提交的做法。最后用git commit -m your message here在新分支上留下一个全新的提交。注意由于经过了撤销 重做新提交的哈希与旧提交不同这是正常现象。三、方案二把最近几个提交移动到新建分支第二种场景是当前分支如master上积累了一连串属于某个新特性的提交你需要把它们整体搬到一个全新的分支同时让master回退到这些提交之前的状态。教程给出的三步方案利用了一个关键事实新建分支时新分支会完整继承当前分支的全部提交历史斯洛文尼亚语原文档第 18-22 行# 1. 在当前提交处创建一个新分支它拥有当前分支的全部提交 git branch newbranch # 2. 把当前分支master硬回退 # 个提交这些提交将从 master 上消失 git reset --hard HEAD~# # 3. 切换到新分支它会保留刚才消失的那几个提交 git checkout newbranch3.1 为什么先建分支再重置能保住提交Git 的分支本质上只是指向某个提交的指针可参见 分支使用指南 中对分支即指向提交的指针的说明。执行git branch newbranch时newbranch指向当前HEAD所在的提交此时无论之后master指针如何移动这些提交仍然被newbranch引用不会丢失。随后git reset --hard HEAD~#把master指针向后移动#个提交#代表要移除的提交数量。关于--hard的语义undoing-a-commit 文档 与 resetting-a-branch 文档 都做了强调--hard不仅移动分支指针还会同时丢弃工作目录与暂存区中的所有改动。3.2 三个需要牢记的风险点原文档在方案二末尾用大写强调了最重要的警告原文档第 24 行Pomembno: Vse spremembe, ki niso bile commit-ane, bodo IZGUBLJENE!重要任何未提交的更改都将丢失结合仓库配套文档方案二还有三处必须注意未提交的改动会丢--hard会清空工作区任何未git add、未git commit的修改都会被永久丢弃被移除的提交不再存在于mastergit reset --hard HEAD~#后这#个提交只保留在newbranch上除非newbranch也被删除不要对已推送的共享分支执行--hard重置undoing-a-commit 文档 明确指出如果提交已经推送到共享仓库git reset --hard会给仓库中的所有人带来问题——改写已公开的历史需要git push --force之类的额外手段风险很高。因此本方案只适用于尚未推送的本地提交。四、两种方案对比与选型建议维度方案一搬到已有分支方案二搬到新建分支适用场景目标分支已存在需要把一批提交独立成新分支处理的提交数最近 1 个可扩展为多个最近#个是否用 stash是保护未提交改动否是否用--hard否用--soft保留改动是移动 master 指针并清空工作区未提交改动被 stash 保护会被丢弃对历史的影响重新生成一个新提交提交哈希不变只是换了归属分支选型建议如果你只想搬运最近一次提交、且未提交的改动还要保留选方案一。它的核心是软重置 stash 保护全程不丢任何内容如果你想把最近若干次提交整体拆到一个新分支常见于在 master 上不小心连续提交了一个新功能选方案二。它利用分支指针实现零拷贝迁移提交哈希保持原样如果搬移之后还想微调提交信息或把多个提交合并成一个可进一步参考仓库的 amending-a-commit 指南 与 squashing-commits 指南。五、安全执行清单综合上述两个方案与仓库配套文档执行移动提交操作前请按此清单自检先看提交历史用git log --oneline参考 check-commit-log 指南确认要移动的提交及数量确认改动都已被提交或已 stash任何未提交的改动在--hard场景下会永久丢失确认目标分支与#数量无误HEAD~#多写一个数字就会多回退一个提交确认提交未被推送到共享远端已推送的提交应改用git revert见 reverting-a-commit 指南或谨慎评估强制推送的后果全程不要中途手动删除 stash方案一中 stash 是未提交改动的唯一副本误删后可用git stash list检查、git stash show -p stash{0} | git apply -R反向撤销已应用的 stash详见 stashing-a-file 指南。六、小结与延伸阅读提交进错分支是 Git 初学者最常遇到的失误之一但修复手段并不复杂方案一用reset --soft与stash实现无损搬运方案二用建分支 硬重置实现整批迁移。二者都以分支是提交的指针这一基本模型为根基理解这一点后任何涉及分支重排的操作都能举一反三。本仓库还提供了成体系的 Git 工作流场景文档可作为进一步学习入口英文原版Moving a commit to a different branch中文版移动提交到不同的分支重置提交 Reset a commit撤销本地提交 Undo local commitsStash 临时保存 Stashing为什么使用分支保持 fork 与上游同步【免费下载链接】first-contributions✨ Help beginners to contribute to open source projects项目地址: https://gitcode.com/gh_mirrors/fi/first-contributions创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
 Docker 部署后跑 Workflow，模型供应商不走 DeepSeek 开放平台、改走 TaoToken 行不行)
