操作git rebase -i Head3失误导致分离求助！

Acsxionian 2020-07-25 12:20:03

萌新不是很懂git，描述不到位！是这样：之前因为提交历史里面有个大文件没办法提交，通过网上方法git rebase -i Head2后，对配置文件第一个保持pick，后面1个变成s。把删除大文件和生成大文件的2次提交合并了，然后提交成功了。
如今又出现这种问题，再次尝试的时候不小心把pick和s的顺序弄反了，导致如图：

现在的代码就变成上次提交的了，不过查看master所在分支还是有最新的代码的，但是不知道怎么切换回来了，求助大神!

...全文

11091 1 打赏收藏举报

写回复

1 条回复

切换为时间正序

请发表友善的回复…

发表回复

独立观察员 2020-07-27

打赏
举报

回复

什么是 pick 和 s ？

推荐使用 GitExtensions 等工具来进行图形化操作。

在使用 Git 进行版本控制时，git rebase 操作虽能让提交历史更清晰，但一旦操作失误，可能导致代码丢失，甚至看似 “删库”，让多天工作量面临风险。本文将详细讲述因 git rebase 出错引发的代码丢失问题，重点介绍 3 行关键指令如何有效找回 3 天工作量，同时科普 Git 的相关机制、rebase 操作的注意事项，以及日常避免类似问题的实用技巧，为开发者提供应对此类危机的完整解决方案，帮助大家在遇到类似情况时能快速止损、恢复工作。合并完成后，还可以删除临时分支：。

大家好，又见面了，我是夜阑的狗🐶，本文是专栏【Git】专栏的第42篇文章;今天又是学习 Git 实战篇的一天，总结在使用 Git 过程中遇到的问题 💖💖💖，开启新的征程，记录最美好的时刻🎉，每天进步一点点。【Git】，此专栏是我是夜阑的狗对Git，Gitee等工具使用过程的总结，希望能够加深自己的印象，以及帮助到其他的小伙伴😉😉。如果文章有什么需要改进的地方还请大佬不吝赐教👏👏。这里给大家推荐一个好用的Git在线练习地址。

Git rebase 是一种提交历史重写机制，其核心原理是将指定范围的提交基于新基线逐个 cherry-pick 并生成全新 commit 对象，从而构建线性、干净、语义清晰的历史图谱。相比 merge 的分叉集成与 cherry-pick 的手动控制，rebase 以自动化拓扑排序和依赖保序能力，精准适配个人功能开发场景，在 Code Review、CI 可追溯性与团队协作规范中展现出显著技术价值。它广泛应用于 PR 前清理、交互式提交整合（squash/reword/edit）、本地分支同步主干等工程实

你是否曾在多人协作中遇到这些问题：错误合并分支导致历史记录混乱？想单独提取某个功能却不知从何下手？本文将通过Git Flight Rules项目中的实战技巧，教你用Cherry-pick和Rebase打造清晰可追溯的提交历史，让团队协作效率提升300%。读完本文你将掌握：选择性提交迁移、交互式变基操作、冲突解决策略三大核心技能。 ## 什么是Git飞行规则 Git Flight Rules（飞...

git rebase -i 修改历史提交 commit 3 add 22222 commit 2 add 11111 commit 1 create file 有如上三次提交，发现第二次提交有失误，准备修改第二次提交。git log –oneline 查看head f206555 add 2222 572a41e add 1111 c1951

.NET技术其他语言

1,979

社区成员

12,447

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章