本文旨在分享作者在遇到版本管理问题时的GIt技巧，希望读者能及时指正、相互学习，优化文章内容。
前言
本文旨在以真实故事的形式分享作者在遇到版本管理问题时的解决方法。T.T||
提示：以下是本篇文章正文内容，下面案例可供参考
一、恢复‘git stash drop’后的代码
如果你本地stash的代码版本过多，在你想要使用‘git stash drop XX’删除XX这一版本的代码时，你手比脑子快一步，没有键入代码commit_id:XX，于是你删掉了最新一版的本地改动，你的命令行此时应该是这样的：
如果你是个小白，此时你会‘啊！’的一声大叫，然后旁边大佬听后只道：‘莫慌！’，并且随手敲下：git show + 上图的commit_id（149825890d1b6c3127c15c3c9d232efe2ccf52fe）。
git show 149825890d1b6c3127c15c3c9d232efe2ccf52fe
这时命令行显示：
于是，大佬笑着对你说，‘小伙子，不要慌，代码还在。’并且转身飞速敲下git diff commit id (展示改动对比，确保是误删除代码)和git diff commit_id > target_commit_patch (将误删代码改动保存为target_commit_patch文件)。
最后，大佬轻松地对正在庆幸的你说道，‘你自己去学习如何把这个patch文件打入我们项目中吧’。
二、将patch文件打入项目代码
你看到大佬轻松地将你的失误抹平，不由得深受激励，心中不免有一股挥斥方遒的豪气：一定要学好技术去蓝翔炒菜！
经过一番努力，你终于在网上学习到打patch的方法：
patch -p0 < patch文件 （如‘一’中的target_commit_patch）
注： -p0 -p1的区别在于是否从patch文件的根目录进行查找。-p0表示从根目录找，-p1表示从根目录的下一级目录查找。
具体可操作流程及说明如下：
D:/yourProject (dev) patch -p0 < target_commit_patch
The text leading up to this was:
--------------------------
|diff --git a/app/src/main/AndroidManifest.xml b/app/src/main/AndroidManifest.xml 【对比两个版本文件差异】
|index cfbbb93..dea84ca 100644
|--- a/gp/src/main/AndroidManifest.xml 【说明：版本1代码文件】
|+++ b/gp/src/main/AndroidManifest.xml 【说明：版本2代码文件】
--------------------------
File to patch: gp/src/main/AndroidManifest.xml
patching file gp/src/main/AndroidManifest.xml
Reversed (or previously applied) patch detected! Assume -R? [n] 【操作：Enter直接回车】
Apply anyway? [n] y 【默认y】
以上操作具有原子性，在一个patch文件的打入过程中可能存在多次此类操作，均可按照上述进行。在这个过程中，你可能会遇到Hunk failed的问题，git会将一些无法合并的代码问题保存为*.java,.rej文件：
Hunk #1 FAILED at 28.
Hunk #2 FAILED at 66.
Hunk #3 FAILED at 101.
Hunk #4 FAILED at 167.
4 out of 4 hunks FAILED -- saving rejects to file app/src/main/entity/ExampleEntity.java.rej
注意：在处理完patch文件后，你的项目里会出现以下两种文件（此两种文件在手动合并所有.rej文件相关代码后，可直接删除）：
’XX.java.rej’ : 被git拒绝自动合进项目的改动，需要开发人员手动去甄别改动进行合并；
’XX.java.orig’ ：这类文件是改动前的缓存代码，可作为对比代码变动的标准版本。
转载请注明出处 [代码视界] https://blog.csdn.net/qq_36307543/article/details/124191207
