博客分类：
传统VCS的回滚操作
对于版本控制系统VCS来说，回滚这个操作应该是个很普通也是很重要的需求。
如果你是传统VCS，比如SVN或者P4来说，revert是个最直观，也是最直接的手段，当然前提是你的修改还没有被提交到远程的中央仓库。
如果你已经ci了你的code到了远程中央仓库，那revert恐怕也无能为力，只能借助其他命令workaroud这个问题，比如：你用SVN的话，就得来个逆向merge操作，把所有的修改都merge回去。
但这样做也有一些弊端：
这次merge会作为一次全新的commit记录记录下来，也就是说它不能真正从你的历史记录里面抹掉你那次不想要的修改。通常情况下其实也没啥大不了的，除非你个人洁癖就是不想看到以前的那次commit记录或者你真的干了啥不想让别人知道的事情。
Git时代的回滚操作
但当发展到git时代，这种回滚操作的复杂度，已经随着git模型本身的特点，变得不那么简单了。
熟悉git的人都知道，为了分布式的需求，git将每一个网络节点作为了一个完整的VCS，也就是每个单台的host在没有网络的前提下，都是一个不受任何影响可以满足除了和其他节点同步（比如：git pull/push这类）之外的几乎所有操作。
为了达到这种效果，git不仅在本地有一个完整的local repository，而且将原本简单的working tree（或者叫working directory）也切成了两块区域——working tree和index（也叫stage）。
这样，光从本地修改的角度来看，你的修改就可能存在三块区域中，working tree、index或者commit之后的历史对象区域。下面我们一个一个各个区域一般都怎么回滚。
working tree内的回滚
这个属于最简单一种情形，本质上说也是和传统VCS中revert直接对应的一种场景，只是这里不叫revert了，而是git checkout，这种情形很简单，这里就不做截图展示了。列出依稀常用的命令形式如下：
git checkout file1 （回滚单个文件）
git checkout file1 file2 ... fileN （一次回滚多个文件，中间用空格隔开即可）
git checkout . （直接回滚当前目录一下的所有working tree内的修改，会递归扫描当前目录下的所有子目录）
index内的回滚
这部分回滚也不复杂，因为这部分的回滚，只要你勤快点使用git status命令，命令的输出上都会给你提示你需要干啥。只是这个过程一般被分为了两步：
将index区域中修改过的文件移除index，也就是恢复到working tree中。这部用git reset来解决。
一旦文件重新回到working tree中，回滚操作就是上面提到的git checkout喽。
这个看个截图直观点：
我working tree下的原始文件信息如下 我修改了a.txt和my_dir/b.txt，并将将他们加入了index区域，当前运行git status得到如下输出
这里再执行git reset . 将当前目录及子目录内的所有修改移出index区域，再次运行git status命令
到这一步之后，就用上面提到git checkout就可以解决问题了。
commit之后的回滚
这种情形是git本地回滚里面最复杂，也是最容易让人迷糊的了，因为针对不同的情况，方法比较多，所以不是很好记。
修改最后一次commit的记录：很多时候先要回滚仅仅是因为自己对最后一次的commit的漏掉（注意，这里说的漏掉不仅仅是你少提交了文件的修改，也包括你多提交了一下你不想要提交的东西）了一些东西，想要回滚这次commit之后再重新commit。如果是这样的话，没有必要真的非要先回滚再重新commit。只要在在自己已经满意了自己所有的修改之后，直接执行git commit --amend，就可以开启上次提交的“补救”提交模式，然后把你对上次所有漏掉的东西加上去就好了。下面看个例子：我进行了一次错误的提交，修改的内容如下： 目前commit 记录如下： 现在我想补救这次commit，相当于取消这次新加入的文件b.txt、取消对a.txt第三行的修改，然后加入我真正想要的修改：在my_dir下增加一个c.txt，并且修改a.txt的第三行为另外一句话。
再次通过git log查看commit记录 请注意比较最新的一次commit的修改，其实已经被修改为另一个SHA1的值了。这里请注意，从某种意义上说（实际上这种替换在reflog中很容易追踪到痕迹，只是在所有的commit逆向引用链条中，我们已经找不到之前的那个fad4...），这种操作已经做到了无痕修改最后一次提交。这和SVN的逆向merge是本质不同的。
回滚中间的某次提交（当然也包括最后一次）：比如我想要回滚上图中倒数第二次提交，就是HEAD^那次，我们先通过git show HEAD^看看那次提交都干了啥？ 然后再通过git revert HEAD^ 来回滚这次操作，然后我们得到了下面的提示： 杯具，冲突了。。。其实，只要你熟悉任何一种VCS工具，想想这个场景，其实也是挺正常的。那就git status看看哪些个文件冲突了吧。 其实你只要仔细看看上面的说明信息，应该已经知道该怎么解决这个冲突了。明显，a.txt是冲突发生的文件： 打开这个文件，可以看到标准的冲突标识文件。这里正是之前我们采用补救式提交方式修改的那句话。至于冲突怎么解决很容易，看你究竟想要啥了，自己去编辑，去掉冲突范围标识符号，保存文件即可。然后按照git正常的流程再次提交，编辑提交的信息即可。再次提交之后的log信息如下： 上面我们基本上演示了一个标准的revert场景（包括了冲突解决），从这个过程可以看出，git revert和SVN的逆向merge几乎如出一辙，就是将你需要回滚的那次commit所做的所有操作，反向操作一次，然后重新做一一个单独的commit对象进行提交。这个过程是否发生冲突，就取决于你的修改了。请注意，这个过程你虽然回滚了你不想要的修改内容，但是你没法抹掉那次commit在history中的信息，请注意上图的第三行，他依旧坚挺的躺在那里。这个也是git revert的特点。当然，git revert实际上也提供-n（--no-commit）参数，用来表示仅将revert的修改体现在当前的working tree，不自动进行提交。但是如果你真的想回滚那些修改的话，再次commit这个环节是逃不掉的。
回滚最后的N次提交（永远从commit的history中抹掉这些记录）：这种场景就轮到git reset登场了。git reset的帮助文档写的非常清楚，在回滚commit的场景中，他的作用就是将当前的HEAD reset到你指定的那个分支。但这个过程中最值得注意的就是你使用的参数，最常用的主要是--soft（个人推荐使用这个，他不会修改你目前index或者working tree中所做的任何修改）/--mixed（你在reset时不加任何参数时的默认行为，会默默把你在index中的修改给灭了！）/--hard（这个是我绝的最危险的参数，会把你index和working tree中的所有修改毁灭的毛都不剩，使用之前请三思，这确实是你要的行为！）这三种。因为我推荐使用--soft参数，下面主要演示回滚到3f412...那次的记录（git reset --soft HEAD~2）： 从上面可以看出来，你的index区域忽然多了很多未提交的修改，这些就是回滚回来的记录，要怎么处理他们，就看你的了。这时我再来看看log的记录信息： 最新的提交已经变成我们希望的那次了。其实从git reset的解释中，我们就可以看出，git reset是一个“斩断”式的回滚操作，因为你把当前的HEAD指针直接移动到了你需要回滚到的那次记录。而git本身的commit链条是逆向回溯的，所以你在提交历史里面再也找不到当前HEAD指向的commit之后的记录了。（不过如果你是git文艺青年的话，你当然知道，想找到那些表面上找不到的commit，通过reflog也是易如反掌）。
好了，到这里，常用的git回滚操作和场景都介绍完了。希望对不熟悉git的TX能有所帮助。
浏览 92896
浏览: 348408 次
来自: 杭州
解决了我的问题, 3q
grep也可以换成sed:find . -name &quot ...
好仔细的文，正愁这问题。很好的解释。
读君一博，解我一周愁
(window.slotbydup=window.slotbydup || []).push({
id: '4773203',
container: s,
size: '200,200',
display: 'inlay-fix'sourceTree 提交修改的时候选择某个文件进行提交 - CSDN博客
sourceTree 提交修改的时候选择某个文件进行提交
提交方式选择“选中的文件”
然后选择需要提交的文件就可以提交了，没有选择的不会提交的
本文已收录于以下专栏：
相关文章推荐
背景：通过bitbucket.org的账号授权登录，找不到密码
项目的输入密码报错，无赖在重新注册账号
通过sourcetree...
sourceTree 切换Git登录用户
换了台电脑，sourceTree保存着原来用户的登录信息。在选项里更新用户信息后，推送代码发现，作者信息还是原来的。没有生效。
解决办法：
http://blog.csdn.net/risky78125/article/details/
http://blog.csdn.net/risky78125/ar...
在Mac下用android studio 开发，结合git sourcetree 进行版本管理。
在新建的类、图片、布局等，都无法提交，studio 上颜色不变红，右键commit ，提示...
1.找到git对应的文件
git status
结果 会得到已经修改的文件。
YYBaby/YYBaby.xcodeproj/xcuse...
git 查看某文件的修改历史
【原文 /articles/YnuYFz】
7.实际运用时遇到的一些问题：
7.1.克隆到本地时老是提示路径不合法，则可能是sourcetree...
我们在使用Git的时候经常会遇到当代码修改已经push上去的时候，却发现有些拼写错误，漏加上文件之类的小错误。这个时候，我们通常的做法是commit，然后再push。其实这个完全没有必要再commit...
我想大家现在都很熟悉github了，也能运用github上开源的项目到自己的项目中。但是我们也很想把自己的一些项目也放到github中开源供大家使用。这2天我就在研究这个东西，也查过很多资料...
前面我们将一个只含有readme文件的项目克隆到了本地，接下来我们修改这个readme文件，并将它上传到Github上，使Github上的文件与本地一致。
1）修改README.md文件，以便我们...
他的最新文章
讲师：钟钦成
讲师：宋宝华
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)解决办法：
小编也是新手，所以在使用SourceTree上面花了不少时间，好在简单的拉去远程代码，同步本地仓库代码搞定了。下面是步骤：
1.我们先去下载一个SourceTree然后打开.
2.下一步，我们需要用SourceTree在本地创建一个本地仓库。
点击New Repository
等待一小会 把代码
拷贝下来。
3.下一步，我点 & &双击本地仓库。（PS 不知道为啥，博客园这编辑器太卡了，实在受不了了）
4.下一步，首先点击setting,然后出现一个下拉栏， 然后你第一使用你是没有关联远程代码仓库的，你需要Add下。
5.下一步，我们配置一下信息。
6.然后我们按 & & OK,进入控制面板，这里所要说的 &是，在这里小编也是新手，给大家建议的使用顺序是（比如你写完你的代码了），commit本地，Pull从远程拉去到本地仓库，最后再把本地仓库代码push到远程代码仓库。
7.最后： 我们在命令行，让远程代码库与服务器代码一致。（） & & & &小编自己辛辛苦苦写的原创，有些不对的地方，大牛指点，别喷我。
阅读(...) 评论()SourceTree 重置当前分支到此次提交 强行合并 - 丢弃所有修改过的工作副本 - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
已注册用户请 &
SourceTree 重置当前分支到此次提交 强行合并 - 丢弃所有修改过的工作副本
04:03:40 +08:00 · 14518 次点击
昨天在使用SourceTree时， 刚想点推送，突然给我显示有几十个文件要拉取。。。
心想先拉取下来看看吧，但是修改的文件已提交，拉取报错了，想丢弃已提交的文件也不行（不知道那里出问题了）。。。
最后只能使用 “重置当前分支到此次提交 强行合并 - 丢弃所有修改过的工作副本” 回到修改之前的分支。
想问一下你对这个“重置当前分支到此次提交 强行合并 - 丢弃所有修改过的工作副本”功能怎么看？
使用这个功能之后，真的是丢弃所有修改过的工作副本了吗？怎么文件夹没变小啊？
如果经常使用这个功能，会不会形成依赖啊。。。
8 回复 &| &直到
11:16:35 +08:00
& & 06:38:29 +08:00 via Android
不知道，只会用命令行。。。
& & 07:59:43 +08:00 via iPad
用完这个功能后本地的提交与修改都没了，不过提交可以找回，通过 git reflog。
建议阅读 Pro Git 第二版，了解 Git 的原理与使用方法。
针对你遇到的问题，正确的做法是：
git add .
git stash
git pull
解决出现的冲突
git push
git stash pop
无法拉取可能是本地修改了一个远程提交也修改的文件，拉取时直接报错，禁止拉取了。对应的解决方案就是先 git stash 存起来，过会儿在 git pull 后 git stash pop 让 git 自动合并，最后可能有冲突，自行解决。
也有可能是拉取后产生冲突了，直接解决冲突即可。
& & 08:04:00 +08:00
有提交的话，一般都不会丢吧。而且最好是一个人用一个分支来工作，之后合到主分支上，这样可以避免混乱，又可以保住自己的工作成果
& & 08:50:03 +08:00
你可以把当前有问题、无法拉取的版本开个新分支存放
```
git checkout -b my_work
```
然后回到master，并重置到没问题的commit
```
git checkout master
git reset --hard 没问题的commit
```
这样你的当前工作在my_work分支上，不会丢失，然后你也可以在master上pull远程改动，本地看看到底哪些文件冲突了
& & 09:00:46 +08:00
不过要是你不是想问这个就无视吧... 才知道v2ex不能删除..
& & 09:09:29 +08:00
换一个角度理解你的问题
& & 09:49:24 +08:00
最好到命令行用git的命令看一下。SourceTree这类工具软件有些设计不太符合git的规范，另外也封装了一些功能，一上来就用工具可能会导致对git理解不透彻。（我们一个新同事用了3个月的SourceTree，前几天才知道git在本地有3层local，stage，repository，因为他用SourceTree每次都是直接commit，根本没有add这个步骤）
& & 11:16:35 +08:00
用工作流啊，每次你自己的开发开启一个工作流分支，这样别人 push 的代码就不会和你的提交直接冲突。
等你的功能开发（并提交）完毕后，将你的工作流分支合并到公共分支上，这时候可以定定心心的处理冲突，冲突解决完后再提交并推送。
& · & 531 人在线 & 最高记录 3541 & · &
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.0 · 56ms · UTC 22:11 · PVG 06:11 · LAX 14:11 · JFK 17:11? Do have faith in what you're doing.}