一、Git 代码撤销、回滚到任意版本（当误提代码到本地或master分支时）
[转]Git 代码撤销、回滚到任意版本（当误提代码到本地或master分支时）
参考URL: https://www.cnblogs.com/wangcp-2014/p/11160125.html
情况一:
代码还只在本地，未push到运程仓库，想把代码还原到上一次commit的代码，此时操作为代码撤销
git reset [–hard|soft|mixed|merge|keep] [commit|HEAD]
1
情况二:代码已经push到运程仓库，想把代码还原到上一次提交，此时操作为代码回滚
回滚到指定的版本（hard后面接的是上面标红的ID,也就是想回滚到的版本）
回退到指定版本，不保留原更改代码
git reset --hard e377f60e28c8b84158
回退到指定版本，保留原更改代码，且生成新的提交
#git revert e377f60e28c8b84158
git push -f origin master
1
2
3
4
5
6
7
注意： revert 是放弃指定提交的修改，但是会生成一次新的提交，需要填写提交注释，以前的历史记录都在；
reset是指将HEAD指针指到指定提交，历史记录中不会出现放弃的提交记录。
一般我们reset 就够用了，记得使用
git push -f origin master。经过测试IDEA，你用IDEA图形化git push上去，默认它会发现，你本地的master revert 的版本小于master，它默认会让你拉。
所以，注意这里手动使用命令
git push -f origin master，这样你远端仓库也就revert到了你指定的版本，成功回滚！
总结： 对于已经push到远端的情况，本地执行git reset ，此时本地文件已经回滚到你指定版本，但是服务器仍然没有改变，需要继续远程回滚： git push -f 执行，远程回滚成功。
二、git回滚命令reset、revert的区别
Git恢复之前版本的两种方法reset、revert（图文详解）
参考URL: https://www.jb51.net/article/192271.htm
git revert 是生成一个新的提交来撤销某次提交，此次提交之前的commit都会被保留.
git reset 是回到某次提交，提交及之前的commit都会被保留，但是此次之后的修改都会被退回到暂存区.
总结： 感觉一般git reset 用的比较多，你也不用担心，你的修改的代码丢失，它默认会放到暂存区，你再commit就可以看到你的修改。
- 背景知识
git的版本管理，及HEAD的理解
使用git的每次提交，Git都会自动把它们串成一条时间线，这条时间线就是一个分支。如果没有新建分支，那么只有一条时间线，即只有一个分支，在Git里，这个分支叫主分支，即master分支。有一个HEAD指针指向当前分支（只有一个分支的情况下会指向master，而master是指向最新提交）。每个版本都会有自己的版本信息，如特有的版本号、版本名等。如下图，假设只有一个分支：
2. 方法一：git reset(回退)
原理： git reset的作用是修改HEAD的位置，即将HEAD指向的位置改变为之前存在的某个版本，如下图所示，假设我们要回退到版本一：
适用场景： 如果想恢复到之前某个提交的版本，且那个版本之后提交的版本我们都不要了，就可以用这种方法。
具体操作：
查看版本号：
可以使用命令“git log”查看：
使用“git reset --hard 目标版本号”命令将版本回退：
再用“git log”查看版本信息，此时本地的HEAD已经指向之前的版本：
使用“git push -f”提交更改：
此时如果用“git push”会报错，因为我们本地库HEAD指向的版本比远程库的要旧：
3. 方法二：git revert(反做)
原理： git revert是用于“反做”某一个版本，以达到撤销该版本的修改的目的。比如，我们commit了三个版本（版本一、版本二、 版本三），突然发现版本二不行（如：有bug），想要撤销版本二，但又不想影响撤销版本三的提交，就可以用 git revert 命令来反做版本二，生成新的版本四，这个版本四里会保留版本三的东西，但撤销了版本二的东西。如下图所示：
————————————————
适用场景： 如果我们想撤销之前的某一版本，但是又想保留该目标版本后面的版本，记录下这整个版本变动流程，就可以用这种方法。
个人不太用，推荐看原作者举例。
开发过程中，你肯定会遇到这样的场景：
场景一：
糟了，我刚把不想要的代码，commit到本地仓库中了，但是还没有做push操作！
场景二：
彻底完了，刚线上更新的代码出现问题了，需要还原这次提交的代码！
场景三：
刚才我发现之前的某次提交太愚蠢了，现在想要干掉它！
撤销
上述场景一，在未进行git push前的所有操作，都是在“本地仓库”中执行的。我们暂且将“本地仓库”的代码还原操作叫做“撤销”！
情况一：文件被修改了，但未执行git add操作（working tree内撤销）
$ git checkout fileName
$ git checkout .
1
2
情况二：同时对多个文件执行了git add操作，但本次只想提交其中一部分文件
$ git add *
$ git status
取消暂存
$ git reset HEAD
1
2
3
4
情况三：文件执行了git add操作，但想撤销对其的修改（index内回滚）
取消暂存
$ git reset HEAD fileName
撤销修改
$ git checkout fileName
1
2
3
4
情况四：修改的文件已被git commit，但想再次修改不再产生新的Commit
修改最后一次提交
$ git add sample.txt
$ git commit --amend -m"说明"
1
2
3
情况五：已在本地进行了多次git commit操作，现在想撤销到其中某次Commit
$ git reset [–hard|soft|mixed|merge|keep] [commit|HEAD]
1
具体参数和使用说明，请查看：Git Pro深入浅出（二）中的重置揭秘部分
回滚
上述场景二，已进行git push，即已推送到“远程仓库”中。我们将已被提交到“远程仓库”的代码还原操作叫做“回滚”！注意：对远程仓库做回滚操作是有风险的，需提前做好备份和通知其他团队成员！
如果你每次更新线上，都会打tag，那恭喜你，你可以很快的处理上述场景二的情况
$ git checkout
1
如果你回到当前HEAD指向
$ git checkout <branch_name>
1
情况一：撤销指定文件到指定版本
查看指定文件的历史版本
$ git log
回滚到指定commitID
$ git checkout
1
2
3
4
情况二：删除最后一次远程提交
方式一：使用revert
$ git revert HEAD
$ git push origin master
1
2
方式二：使用reset
$ git reset --hard HEAD^
$ git push origin master -f
1
2
二者区别：
revert 是放弃指定提交的修改，但是会生成一次新的提交，需要填写提交注释，以前的历史记录都在；
reset 是指将HEAD指针指到指定提交，历史记录中不会出现放弃的提交记录。
情况三：回滚某次提交
找到要回滚的commitID
$ git log
$ git revert commitID
1
2
3
删除某次提交
$ git log --oneline -n5
————————————————
https://blog.csdn.net/ligang2585116/article/details/7109488
1
注意： 需要注意最后的*^*号，意思是commit id的前一次提交
$ git rebase -i “5b3ba7a”^
在编辑框中删除相关commit，如pick 5b3ba7a test2，然后保存退出（如果遇到冲突需要先解决冲突）！
$ git push origin master -f
1
通过上述操作，如果你想对历史多个commit进行处理或者，可以选择git rebase -i，只需删除对应的记录就好。rebase还可对 commit 消息进行编辑，以及合并多个commit。
————————————————
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
一、前言
1、什么是冲突
冲突是指当你在提交或者更新代码时被合并的文件与当前文件不一致。读起来有点绕，结合下面的案例理解。
从上面对冲突的定义来看，冲突时发生在同一个文件上的。
二、实战分析
1、生产上冲突的场景
1.2、常见冲突的生产场景如下：
更新代码
提交代码
多个分支代码合并到一个分支时
多个分支向同一个远端分支推送代码时
1.3、git的合并中产生冲突的具体情况：
两个开发者（分支中）修改了同一个文件（不管什么地方）
两个开发者（分支中）修改了同一个文件的名称
注意： 两个分支中分别修改了不同文件中的部分，不会产生冲突，可以直接将两部分合并。
总结： 上面各种情况的本质都是，当前文件与合并文件不一致，因此不论哪种情况其解决冲突的方法是一样的。
1.4、强制回滚到指定的提交记录版本
场景：当我们有时候在自己的本地上失误修改了东西，或则出现了很多冲突合并失败的代码。那么这个时候保持没有意外的情况下，可以直接回滚到最新提交记录的那个版本，这样就能一下子复原。
三、idea中解决冲突
1、模拟场景分析
假设有另个开发人员开发同一个项目，并且编写同一个文件,工作流程如下：
01号程序员先上传文件 conflict.txt，并继续在 conflict.txt上写代码
02号程序员更新项目代码，并在 conflict.txt 上写代码，写完后，在提交到远程服务端
当01号程序员把写完后，准备提交代码了，这时的正规操作手法，先更新在提交，但是在更新的时候必然会冲突，因为这时候更新的代码 conflict.txt 与本地仓库代码 conflict.txt 不一致
提交前，我要更新，冲突了：
解决上图中的冲突方案如下：
Accept Yours：代表以自己的为准
Accept Theris：代表以更新下来的文件为准
Merge：代表手动合并
一般解决冲突我们都是选择 Merge
将需要的内容点击：">>"既可以合并内容到 result 中，不需要的内容点击“x”即可，合并完成后点击 apply 即可。
值得注意的是，最后将所有的“x >>”符号都要处理完，不需要的点击“x”,需要的点击“>>”
最后，不论是什么场景下产生的冲突解决方法是一样的。
四、关于冲突的个人心得
多人协作开发的时候如果出现了你没有改过的文件跟你冲突了，一定要去找到当事者，说清楚是如何冲突的。
然后协商解决，千万不要擅自拉别的分支去试图解决冲突，或找文件覆盖，更或者以自己的文件为准。
同时记住解决了之后要add 和 commit 最后push，为保证万无一失，最后在冲突都解决之后重启项目。
保证至少不会有立即奔溃的现象发生然后才去提交push
提交的时候一定要保持清醒先搞清楚自己要提交的文件之间的关系然后再提交，这样才不会有文件缺失的问题造成奔溃
如果任务比较多又开了多个分支分别进行开发，再次强调一定要清楚自己在各个分支上做了什么，自己要提交的是什么，最好是能做个详细的笔记，没有把握宁愿不要去提交到生产服务器
提交代码的时候不要走神，因为这是一个神圣的时刻。
https://blog.csdn.net/Mango_Bin/article/details/122382065