first-contributions 仓库实战Git 将提交Commit移动到另一个分支的完整指南【免费下载链接】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含越南语译文 moving-a-commit-to-a-different-branch.vi.md为骨架展开。当你提交了一个更改后却突然发现自己提交到了错误的分支——这在日常开发、尤其是为开源项目做贡献时非常常见。读完本文你将掌握两套标准解法把最新提交“搬”到已有分支以及把最新提交“搬”到一个全新分支并理解reset、stash、checkout、branch等命令在其中的精确作用与风险边界。问题场景提交到了错误的分支在 Git 的工作流中每个分支只是指向项目历史中某个提交的指针详见仓库中的 why-using-branches.md。由于切换分支时只需移动指针开发者常常在未确认当前分支的情况下直接提交于是出现如下状况你在main或master分支上完成了一个功能并git commit但事后发现这个更改本应属于另一个特性分支已有分支或者这个更改应该单独开辟一个新分支来承载。原文档提出了一个核心问题如果你提交了一个更改然后意识到提交到了错误的分支该如何修改下文给出两条标准路径分别对应移动到已有分支与移动到新分支两种目标。在动手之前请先用git log --oneline确认当前分支的提交历史这是所有 Git 回退操作的前置检查详细用法可参考仓库中的 check-commit-log.md$ git log --oneline a1b2c3d fix: correct typo in README # - 你想移动的这个提交HEAD e4f5g6h add feature skeleton i7j8k9l initial commit方案一将最新的提交移动到已有分支这是原文档给出的第一个场景目标分支已经存在例如feature/login你希望把刚提交的更改整体搬到该分支上。完整命令序列如下git reset HEAD~ --soft # 撤销最后一次提交但保留所有更改回到暂存区 git stash # 把当前工作区与暂存区的状态暂存起来 git checkout name-of-the-correct-branch # 切换到正确的目标分支 git stash pop # 恢复最近一次暂存的更改 git add . # 将更改加入暂存区也可逐个文件 add git commit -m your message here # 在新的分支上重新提交执行完毕后你的更改就出现在正确的分支上了。下面逐条拆解每个命令的原理与注意事项。第一步git reset HEAD~ --soft—— 撤销提交但保留更改git reset用于把仓库回退到某个提交状态。这里HEAD~表示当前提交HEAD的前一个提交即撤销最后一次提交。而--soft模式意味着只移动分支指针不触碰工作区与暂存区——提交被撤下了但文件的更改内容依然保留此时它们处于已暂存状态随时可以重新提交。原理对照仓库中的 undoing-a-commit.md 专门讲解了git reset撤销本地提交的三种层次——不带参数的git reset只清空暂存区git reset file只将指定文件移出暂存区而git reset --hard会连同工作区修改一起丢弃。--soft与这三种都不同它连暂存区都保留是纯粹撤销提交、不动内容的最温和方式。具体机制可进一步参考 resetting-a-commit.md。第二步git stash与git checkout—— 安全切换分支git stash会把当前工作目录的脏状态已修改、未提交的更改记录到暂存栈中让工作区恢复干净从而允许你在不丢失更改的前提下切换分支。仓库中的 stashing-a-file.md 对 stash 机制有完整演示$ git stash Saved working directory and index state WIP on master: 049d078 added the index file HEAD is now at 049d078 added the index file随后git checkout name-of-the-correct-branch切换到正确的目标分支。注意如果工作区有未提交更改Git 通常会拒绝切换分支这正是必须先git stash的原因。第三步git stash pop、git add与git commit—— 在新分支重新落地git stash pop从暂存栈中取出最近一次 stash 并应用到当前工作区同时从栈中删除该 stash 记录。若想保留栈中记录只做应用可用git stash apply查看栈内容可用git stash list丢弃指定 stash 可用git stash drop stash{n}。git add .将更改加入暂存区。原文档特别注明或尝试单独添加文件即可以git add file1 file2按需精准暂存。git commit -m your message here在正确的分支上完成新提交消息内容可沿用原提交消息也可重新撰写。至此错误分支上已不再包含该提交因第一步reset --soft已将其摘下而正确的分支上出现了携带相同更改的全新提交。方案二将最新的提交移动到新分支如果目标分支尚不存在原文档给出了第二种方案先用git branch创建新分支再用git reset --hard把旧分支回退最后git checkout到新分支git branch newbranch # 创建一个新分支保留当前分支的所有提交 git reset --hard HEAD~# # 将当前分支回退 # 个提交# 为要移动的提交个数 git checkout newbranch # 切换到新分支所有被移动的提交都在这里请务必牢记原文档的红色警告任何未包含在提交中的更改未提交的修改将在此过程中被完全丢失LOST。第一步git branch newbranch—— 创建分支并复制提交git branch newbranch会基于当前 HEAD 创建一个新分支指针。由于新建分支时指针指向当前提交当前分支的全部提交历史被完整保留在新分支上。这一步只是创建指针不会切换分支也不会删除任何提交。第二步git reset --hard HEAD~#—— 回退当前分支HEAD~#表示当前提交之前的第#个提交#是你要移动的提交数量。git reset --hard HEAD~#会将当前分支指针回退#个提交并同时丢弃这#个提交带来的文件更改——注意这些提交本身并不会被删除因为第一步创建的newbranch仍然完整地持有它们。模式对比--hard会彻底丢弃工作区与暂存区中所有对应更改风险最高--soft保留更改缺省模式--mixed保留工作区更改但清空暂存区。仓库中的 resetting-a-branch.md 还给出了工业场景下的典型用法git reset stage master --hard将stage分支完全重置为master的状态并指出当 CI/CD 流水线或进行中的工作流不允许直接删除分支时git reset是更安全的替代方案。第三步git checkout newbranch—— 登上承载提交的新分支此时newbranch指针仍停留在移动前的提交上git checkout newbranch切换过去后你会看到所有本应属于该分支的提交都在这里历史记录完好无损。两种方案的对比与适用场景对比维度方案一移动到已有分支方案二移动到新分支目标分支已存在如feature/login尚不存在需新建撤销命令git reset HEAD~ --soft保留更改git reset --hard HEAD~#丢弃更改变更搬运方式stash→checkout→stash pop→ 重新提交branch先复制 →reset回退 →checkout切换未提交更改会被 stash 妥善保存会彻底丢失提交消息可在新分支重新编写原提交消息原样保留风险等级低全程无数据丢失中--hard不可逆务必先确认无未提交更改核心选型原则如果目标分支已存在优先用方案一——它全程温和任何一步出错都能通过 stash 找回更改如果目标分支不存在且你希望原样保留提交历史用方案二——但执行git reset --hard之前必须先用git status确认没有未提交的修改。使用注意与边界条件--hard不可逆方案二中的git reset --hard HEAD~#会永久丢弃旧分支上对应提交的工作区更改。原文档明确警告任何未提交的更改将完全丢失执行前务必确认。仅限本地未推送的提交仓库 undoing-a-commit.md 特别提醒——如果这些提交已经推送到共享远程仓库绝对不要使用git reset --hard否则会给仓库中的所有人带来混乱。此时应改用git revert生成一个反向新提交参考 reverting-a-commit.md。stash 栈是后进先出多次 stash 时git stash pop默认弹出最近一次stash{0}。如果目标不是最新一次需显式指定如git stash pop stash{2}。分支命名规范在开源贡献场景中建议遵循一个特性一个分支的惯例参见 why-using-branches.md例如feature/xxx、fix/yyy避免把多个无关提交混入同一分支。中文译文版本本文对应的越南语译文位于 docs/additional-material/translations/Vietnamese/moving-a-commit-to-a-different-branch.vi.md中文版本见 docs/additional-material/translations/Chinese/moving-a-commit-to-a-different-branch.zh-cn.md多语言读者可对照查阅。总结把提交移动到另一个分支本质上就是撤销 重新提交的组合操作方案一用git reset --soft温和地摘下提交借助stash安全换分支后再提交方案二用git branch先复制提交历史再用git reset --hard清空旧分支最后切到新分支。掌握这两套流程配合git log --oneline的事前检查与git status的事前确认你就能在 first-contributions 这类开源协作场景中从容处理提交错了分支的尴尬并且全程不丢失任何代码。【免费下载链接】first-contributions✨ Help beginners to contribute to open source projects项目地址: https://gitcode.com/gh_mirrors/fi/first-contributions创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 first-contributions 仓库实战：Git 将提交（Commit）移动到另一个分支的完整指南
first-contributions 仓库实战Git 将提交Commit移动到另一个分支的完整指南【免费下载链接】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含越南语译文 moving-a-commit-to-a-different-branch.vi.md为骨架展开。当你提交了一个更改后却突然发现自己提交到了错误的分支——这在日常开发、尤其是为开源项目做贡献时非常常见。读完本文你将掌握两套标准解法把最新提交“搬”到已有分支以及把最新提交“搬”到一个全新分支并理解reset、stash、checkout、branch等命令在其中的精确作用与风险边界。问题场景提交到了错误的分支在 Git 的工作流中每个分支只是指向项目历史中某个提交的指针详见仓库中的 why-using-branches.md。由于切换分支时只需移动指针开发者常常在未确认当前分支的情况下直接提交于是出现如下状况你在main或master分支上完成了一个功能并git commit但事后发现这个更改本应属于另一个特性分支已有分支或者这个更改应该单独开辟一个新分支来承载。原文档提出了一个核心问题如果你提交了一个更改然后意识到提交到了错误的分支该如何修改下文给出两条标准路径分别对应移动到已有分支与移动到新分支两种目标。在动手之前请先用git log --oneline确认当前分支的提交历史这是所有 Git 回退操作的前置检查详细用法可参考仓库中的 check-commit-log.md$ git log --oneline a1b2c3d fix: correct typo in README # - 你想移动的这个提交HEAD e4f5g6h add feature skeleton i7j8k9l initial commit方案一将最新的提交移动到已有分支这是原文档给出的第一个场景目标分支已经存在例如feature/login你希望把刚提交的更改整体搬到该分支上。完整命令序列如下git reset HEAD~ --soft # 撤销最后一次提交但保留所有更改回到暂存区 git stash # 把当前工作区与暂存区的状态暂存起来 git checkout name-of-the-correct-branch # 切换到正确的目标分支 git stash pop # 恢复最近一次暂存的更改 git add . # 将更改加入暂存区也可逐个文件 add git commit -m your message here # 在新的分支上重新提交执行完毕后你的更改就出现在正确的分支上了。下面逐条拆解每个命令的原理与注意事项。第一步git reset HEAD~ --soft—— 撤销提交但保留更改git reset用于把仓库回退到某个提交状态。这里HEAD~表示当前提交HEAD的前一个提交即撤销最后一次提交。而--soft模式意味着只移动分支指针不触碰工作区与暂存区——提交被撤下了但文件的更改内容依然保留此时它们处于已暂存状态随时可以重新提交。原理对照仓库中的 undoing-a-commit.md 专门讲解了git reset撤销本地提交的三种层次——不带参数的git reset只清空暂存区git reset file只将指定文件移出暂存区而git reset --hard会连同工作区修改一起丢弃。--soft与这三种都不同它连暂存区都保留是纯粹撤销提交、不动内容的最温和方式。具体机制可进一步参考 resetting-a-commit.md。第二步git stash与git checkout—— 安全切换分支git stash会把当前工作目录的脏状态已修改、未提交的更改记录到暂存栈中让工作区恢复干净从而允许你在不丢失更改的前提下切换分支。仓库中的 stashing-a-file.md 对 stash 机制有完整演示$ git stash Saved working directory and index state WIP on master: 049d078 added the index file HEAD is now at 049d078 added the index file随后git checkout name-of-the-correct-branch切换到正确的目标分支。注意如果工作区有未提交更改Git 通常会拒绝切换分支这正是必须先git stash的原因。第三步git stash pop、git add与git commit—— 在新分支重新落地git stash pop从暂存栈中取出最近一次 stash 并应用到当前工作区同时从栈中删除该 stash 记录。若想保留栈中记录只做应用可用git stash apply查看栈内容可用git stash list丢弃指定 stash 可用git stash drop stash{n}。git add .将更改加入暂存区。原文档特别注明或尝试单独添加文件即可以git add file1 file2按需精准暂存。git commit -m your message here在正确的分支上完成新提交消息内容可沿用原提交消息也可重新撰写。至此错误分支上已不再包含该提交因第一步reset --soft已将其摘下而正确的分支上出现了携带相同更改的全新提交。方案二将最新的提交移动到新分支如果目标分支尚不存在原文档给出了第二种方案先用git branch创建新分支再用git reset --hard把旧分支回退最后git checkout到新分支git branch newbranch # 创建一个新分支保留当前分支的所有提交 git reset --hard HEAD~# # 将当前分支回退 # 个提交# 为要移动的提交个数 git checkout newbranch # 切换到新分支所有被移动的提交都在这里请务必牢记原文档的红色警告任何未包含在提交中的更改未提交的修改将在此过程中被完全丢失LOST。第一步git branch newbranch—— 创建分支并复制提交git branch newbranch会基于当前 HEAD 创建一个新分支指针。由于新建分支时指针指向当前提交当前分支的全部提交历史被完整保留在新分支上。这一步只是创建指针不会切换分支也不会删除任何提交。第二步git reset --hard HEAD~#—— 回退当前分支HEAD~#表示当前提交之前的第#个提交#是你要移动的提交数量。git reset --hard HEAD~#会将当前分支指针回退#个提交并同时丢弃这#个提交带来的文件更改——注意这些提交本身并不会被删除因为第一步创建的newbranch仍然完整地持有它们。模式对比--hard会彻底丢弃工作区与暂存区中所有对应更改风险最高--soft保留更改缺省模式--mixed保留工作区更改但清空暂存区。仓库中的 resetting-a-branch.md 还给出了工业场景下的典型用法git reset stage master --hard将stage分支完全重置为master的状态并指出当 CI/CD 流水线或进行中的工作流不允许直接删除分支时git reset是更安全的替代方案。第三步git checkout newbranch—— 登上承载提交的新分支此时newbranch指针仍停留在移动前的提交上git checkout newbranch切换过去后你会看到所有本应属于该分支的提交都在这里历史记录完好无损。两种方案的对比与适用场景对比维度方案一移动到已有分支方案二移动到新分支目标分支已存在如feature/login尚不存在需新建撤销命令git reset HEAD~ --soft保留更改git reset --hard HEAD~#丢弃更改变更搬运方式stash→checkout→stash pop→ 重新提交branch先复制 →reset回退 →checkout切换未提交更改会被 stash 妥善保存会彻底丢失提交消息可在新分支重新编写原提交消息原样保留风险等级低全程无数据丢失中--hard不可逆务必先确认无未提交更改核心选型原则如果目标分支已存在优先用方案一——它全程温和任何一步出错都能通过 stash 找回更改如果目标分支不存在且你希望原样保留提交历史用方案二——但执行git reset --hard之前必须先用git status确认没有未提交的修改。使用注意与边界条件--hard不可逆方案二中的git reset --hard HEAD~#会永久丢弃旧分支上对应提交的工作区更改。原文档明确警告任何未提交的更改将完全丢失执行前务必确认。仅限本地未推送的提交仓库 undoing-a-commit.md 特别提醒——如果这些提交已经推送到共享远程仓库绝对不要使用git reset --hard否则会给仓库中的所有人带来混乱。此时应改用git revert生成一个反向新提交参考 reverting-a-commit.md。stash 栈是后进先出多次 stash 时git stash pop默认弹出最近一次stash{0}。如果目标不是最新一次需显式指定如git stash pop stash{2}。分支命名规范在开源贡献场景中建议遵循一个特性一个分支的惯例参见 why-using-branches.md例如feature/xxx、fix/yyy避免把多个无关提交混入同一分支。中文译文版本本文对应的越南语译文位于 docs/additional-material/translations/Vietnamese/moving-a-commit-to-a-different-branch.vi.md中文版本见 docs/additional-material/translations/Chinese/moving-a-commit-to-a-different-branch.zh-cn.md多语言读者可对照查阅。总结把提交移动到另一个分支本质上就是撤销 重新提交的组合操作方案一用git reset --soft温和地摘下提交借助stash安全换分支后再提交方案二用git branch先复制提交历史再用git reset --hard清空旧分支最后切到新分支。掌握这两套流程配合git log --oneline的事前检查与git status的事前确认你就能在 first-contributions 这类开源协作场景中从容处理提交错了分支的尴尬并且全程不丢失任何代码。【免费下载链接】first-contributions✨ Help beginners to contribute to open source projects项目地址: https://gitcode.com/gh_mirrors/fi/first-contributions创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考