使用 Git 工作时其中一个鲜为人知(和没有意识到)的方面就是,如何轻松地返回到你以前的位置 —— 也就是说,在仓库中如何很容易地去撤销那怕是重大的变更。...在本文中,我们将带你了解如何去重置、恢复和完全回到以前的状态,做到这些只需要几个简单而优雅的 Git 命令。 重置 我们从 Git 的 reset 命令开始。...实际上,它重置了(清除掉)暂存区,并用你重置的提交内容去覆盖了工作区中的内容。在你使用 hard 选项之前,一定要确保这是你真正地想要做的操作,因为这个命令会覆盖掉任何未提交的更改。...当我们以这种方式使用 Git 工作时,我们的基本规则之一是:在你的本地仓库中使用这种方式去更改还没有推送的代码是可以的。...从本质上来说,Git 将一个分支中的每个不同提交尝试“重放”到另一个分支中。
A的时候,修改了一下此功能依赖的,且tracked by另一条功能分支B的文件(实际上这是常有的事),那么为了做好版本控制你不会将这个文件的修改提交到分支A上,但是在这种情况在git中,你还未提交时git...想想以前还是将整个目录打包成压缩文件并给个label... 可能对于git新手来说,并不能很好地使用版本控制,往往将一堆文件的修改一次性地提交。...checkout Situation:我们知道git checkout是用于切换分支的一个命令,但是我们却可以用它来干一些常用的事~比如: 当我们想放弃一些还未提交的无用修改时,可以用checkout...来还原文件的内容 当我们需要将版本回滚到比较久远的一个状态,或者说在分支合并之前的状态时,可以用git checkout来回滚。...(你甚至可以做些修改并提交) // 保留当前的状态,在一个新建的分支上 $ git checkout -b hotfix // 强行回滚远程master到本地的hotfix分支的状态 $ git push
我们可以测试一下,对一个文件进行更改,然后把更改添加(使用git add)到暂存区,然后再次添加一个更改,这次不添加到暂存区。...14fefac update 2 fd01444 add README.md 3c76ad1 init 找到我们添加新功能时,当前分支所处的提交。...我们需要运行下面的命令: git reset fd01444 # fd01444是某次提交的hash值 如果没有指明重置的模式的话,默认会使用--mixed模式,这样的话我们在fd01444这次提交之后的所有提交都会被重置为没有提交的状态...git reset # 将当前分支重置到新功能开发之前的提交 接下来我们现在的状态就回到了新功能还没有提交的状态,那么就可以继续使用git stash相关的命令去操作了。...然后我们回到最初的分支,再次运行git reset 命令,把已提交的内容进行重置,然后运行命令: git checkout -- .
在屏幕截图下,你会看到这个命令就像一个巨大的源: 04 审核源的历史 我们已经在以前的教程中了解过 git log 的运用了,但是这里仍然有你需要知道的三个选项。...后面,你意识到这个过程丢失了一些其他的信息并想返回去,或者至少可以再次看下。这就是 git reflog 作用。 一个简单的 git log 命令可以显示最新的提交,上一次的提交,上上次的提交等等。...然而,git reflog是一个被指向提交的列表。记住:这是你系统的局部,不是源的部分,不包含推送的和合并的。 如果执行 git log,我获取的提交信息是源的一部分。...然而,当你执行硬重置时,git reflog 展示了提交信息(b1b0ee9–HEAD@)是丢失的。...让我们看看当我们添加一个前缀 -p 至 add 命令上发生了什么。 似乎 Git 假设所有的改变都是同样的,因此,将它们分成一个大块。
现在做项目 Git 代码管理是一定少不了的。 多年以前可能是 SVN,我想如今的公司里面基本都转型到用 Git 了吧。...-m [message] # 提交工作区自上次commit之后的变化,直接到仓库区 $ git commit -a # 提交时显示所有diff信息 $ git commit -v # 使用一次新的commit...或者代码里程碑时使用到,目的是标记一个时间点,等后期可以快速定位到这个点的代码。...] # 显示某次提交发生变化的文件 $ git show --name-only [commit] # 显示某次提交时,某个文件的内容 $ git show [commit]:[filename] #...[file] # 恢复某个commit的指定文件到暂存区和工作区 $ git checkout [commit] [file] # 恢复暂存区的所有文件到工作区 $ git checkout. # 重置暂存区的指定文件
,包括已经撤销的(其实git 回定期清除用不到的对象,所以时间太长久,分支改动删除了的,就不要指望记录还在了)。...SHA,然后通过git cherry-pick SHA把那几个提交撤销重置。...当然你可以直接 merge 或者 reset 暂存更新再重新提交,但是这里有一种更加优雅的做法时 rebase。...master 末尾,然后再重新 commit 暂存的 new_fea 提交 撤销多个不连续的commit 场景:需要修改到一个早期提交的消息;发现一个早期提交漏了一些修改,想把几个提交合并,让log更加简洁的时候等可以尝试以下方法...聚集反物质,把你之前的提交抵消掉,回产生一条新记录,但是内容被重置。
如下图,硬重置不保留已提交的修改,直接将当前分支的状态恢复到某个特定提交下,同时将当前工作区和暂存区中的文件全部移除。 [reset-hard.gif] 3....常见场景操作 场景1:工作区某文件内容改错,想直接丢弃工作区的修改时: $ git checkout -- [file name] 场景2.1:改错的文件添加到了暂存区,未提交版本库,想清除暂存区的修改...场景2.2:改错的文件添加到了暂存区,未提交版本库,想直接清除本地所有修改时: # 清空暂存区,清空工作区 $ git reset --hard HEAD 等同于 场景2.1 + 场景1。...场景3.1:改错的文件已提交版本库,但未提交远程库,想撤销上次提交,重新放回工作区时: $ git reset HEAD^ 场景3.2:改错的文件已提交版本库,但未提交远程库,想撤销上次提交,上次提交内容直接丢弃时...reset 的 hard 参数重置 HEAD 指针到最新记录,刷新暂存区和工作区状态,找回版本库中的删除文件 # 删除操作已提交到本地库 $ git reset --hard [历史记录指针位置] #
2.集中版本控制 所有的版本数据都保存在服务器上,协同开发者从服务器上同步更新或上传自己的修改,所有的版本数据都存在服务器上,用户的本地只有自己以前所同步的版本,如果不连网的话,用户就看不到历史版本,也无法切换版本验证问题...3.分布式版本控制 所有版本信息仓库全部同步到本地的每个用户,这样就可以在本地查看所有版本历史,可以离线在本地提交,只需在连网时 push 到相应的服务器或其他用户那里。...: 未跟踪, 此文件在文件夹中, 但并没有加入到git库, 不参与版本控制....-m [message] # 提交工作区自上次commit之后的变化,直接到仓库区 $ git commit -a # 提交时显示所有diff信息 $ git commit -v # 使用一次新的...commit] # 显示某次提交发生变化的文件 $ git show --name-only [commit] # 显示某次提交时,某个文件的内容 $ git show [commit]:[filename
我发现在使用 Git 时,在头脑里可视化地想象它会非常有用:当我执行一个特定命令时,这些分支会如何交互,又会怎样影响历史记录?...为什么当我在 master 上执行硬重启,force push 到原分支以及 rimraf 我们的 .git 文件夹时,我的同事哭了?...另一种可将一个分支的修改融入到另一个分支的方式是执行 git rebase。 git rebase 会将当前分支的提交复制到指定的分支之上。 ?...交互式变基能为你在 rebase 时提供大量控制,甚至可以控制当前的活动分支。 重置(Resetting) 当我们不想要之前提交的修改时,就会用到这个命令。...硬重置 有时候我们并不想保留特定提交引入的修改。不同于软重置,我们应该再也无需访问它们。Git 应该直接将整体状态直接重置到特定提交之前的状态:这甚至包括你在工作目录中和暂存文件上的修改。 ?
但是,所有的版本数据都存在服务器上,用户的本地设备就只有自己以前所同步的版本,如果不连网的话,用户就看不到历史版本,也无法切换版本验证问题,或在不同分支工作。...DVCS不是复制指定版本的快照,而是把所有的版本信息仓库全部同步到本地,这样就可以在本地查看所有版本历史,可以离线在本地提交,只需在连网时push到相应的服务器或其他用户那里。...当我们往工作目录添加一个文件的时候,这个文件默认是未跟踪状态的,我们肯定不希望编译生成的一大堆临时文件默认被跟踪还要我们每次手动将这些文件清除出去。...当我们修改了一些文件后,要将其放入暂存区然后才能提交,每次提交时其实都是提交暂存区的文件到git仓库,然后清除暂存区。...这是因为当我们暂存一从此文件时,暂存的是那一文件当时的版本,当暂存后再次修改了这个文件后就会提示这个文件暂存后的修改是未被暂存的。
我发现在使用 Git 时,在头脑里可视化地想象它会非常有用:当我执行一个特定命令时,这些分支会如何交互,又会怎样影响历史记录?...为什么当我在 master 上执行硬重启,force push 到原分支以及 rimraf 我们的 .git 文件夹时,我的同事哭了?...另一种可将一个分支的修改融入到另一个分支的方式是执行 git rebase。 git rebase 会将当前分支的提交复制到指定的分支之上。...交互式变基能为你在 rebase 时提供大量控制,甚至可以控制当前的活动分支。 重置(Resetting) 当我们不想要之前提交的修改时,就会用到这个命令。...Git 应该直接将整体状态直接重置到特定提交之前的状态:这甚至包括你在工作目录中和暂存文件上的修改。 Git 丢弃了 9e78i 和 035cc 引入的修改,并将状态重置到了 ec5be 的状态。
失误提交 失误合并 失误变基 失误重置 不知道为啥...就失误了 分享一个 Git 思维导图: 高清版下载:https://www.processon.com/mindmap/5f6eeefde401fd64b5dc1eee...当你要合并分支时,务必知道当前位于哪个分支上。注意,合并分支会提交 commit。 当我们合并时: 我们将其他分支合并到当前(检出的)分支上。 我们不是将两个分支合并到一个新的分支上。...重置 commit 一定要谨慎使用 git 的重置功能。这是少数几个可以从仓库中清除 commit 的命令。如果某个 commit 不再存在于仓库中,它所包含的内容也会消失。...第一个父 commit 是当你运行 git merge 时所处的分支,而第二个父 commit 是被合并的分支。...13.3.2. git reset 命令 git reset 命令用来重置(清除)commit: git reset 可以用来: 将 HEAD 和当前分支指针移到目标
当对工作区修改(或新增)的文件执行 “git add” 命令时,暂存区的目录树被更新,同时工作区修改(或新增)的文件内容被写入到对象库中的一个新的对象中,而该对象的ID被记录在暂存区的文件索引中。...当执行提交操作(git commit)时,暂存区的目录树写到版本库(对象库)中,master 分支会做相应的更新。即 master 指向的目录树就是提交时暂存区的目录树。...或者 “git checkout – ” 命令时,会用暂存区全部或指定的文件替换工作区的文件。这个操作很危险,会清除工作区中未添加到暂存区的改动。...的区别: reset是重置,默认是git reset –mixed 可以让版本库重置到某个commit状态,该commit之后的commit不会保留,并重置暂存区,但是不改变工作区。...即这个时候,上次提交的内容在工作区中还会存在。 如果使用git reset –hard 将版本库,暂存区和工作区的内容全部重置为某个commit的状态。之前的commit不会保留。
以前自己在win下使用git的时候都是使用的desktop版本的,现在切换到linux系统不得不适用命令行来做了。...git reset --hard 版本号 可以重置为特定版本,版本号很长可以不用写全,写上4,5位一般就可以了。...cat filename可以显示文档内容 git reflog可以记录你的每一次命令,所以即使是返回了以前的版本,而且电脑也挂机了,新版本的ID还是可以找到的。 git暂存区。 ?...这个概念很重要,可以通过上图来理解,工作区是当前的文件夹,git文件里存的是版本库,版本库是来控制工作区的,当我们在工作区修改文件之后,可以通过add命令来添加到暂存区,然后commit可以一次性把所有暂存区的修改提交...git checkout --filename可以丢弃工作区的内容,如果这次操作还没有提交过到暂存区,那么所有修改都被撤销,如果有add到暂存区,那么这条命令就会恢复到提交暂存区之后的状态。
1.可以通过git-commit -m"注释",必须得有注释,不然不能提交. 2.git-commit还有一个–a的参数,可以将那些没有通过git-add标识的变化一并强行提交,但是不建议使用这种方式...这条命令将从远端git库的远端分支名获取到本地git库的一个本地分支中。其中,如果不写本地分支名,则默认pull到本地当前分支。需要注意的是,git-pull也可以用来合并分支。...如git-reset [--mixed] dev1^(dev1^的定义可以参见2.6.5)。它的作用仅是重置分支状态到dev1^, 但是却不改变任何工作文件的内容。...即,从dev1^到dev1的所有文件变化都保留了,但是dev1^到dev1之间的所有commit日志都被清除了,而且,发生变化的文件内容也没有通过git-add标识,如果您要重新commit,还需要对变化的文件做一次...--hard 这个命令就会导致所有信息的回退, 包括文件内容。 一般只有在重置废弃代码时,才用它。执行后,文件内容也无法恢复回来了。
Release 分支 - 发布分支:用于发布准备的专门分支。当开发进行到一定程度,或者说快到了既定的发布日,可以发布时,建立一个 release 分支并指定版本号(可以在 finish 的时候添加)。...Footer 不兼容变动(需要说明变动信息) 关闭issue(需要输入issue信息) 使用 Git 时常会遇到的各种突发状况 git stash 【1】场景重现 one:当正在 feature 分支上开发某个新功能...【2】场景重现 two:当你在功能分支上开发新 feature 时,多次提交了记录,这时,想要在在合并 feature 分支到 master 之前清理其杂乱的历史记录。...当我们需要在本地合入其他分支的提交时,如果我们不想对整个分支进行合并,而是只想将某一次提交合入到本地当前分支上,那么就要使用 git cherry-pick 了。...git revert 之后你再 git push 既可以把线上的代码更新。git revert 是放弃指定提交的修改,但是会生成一次新的提交,需要填写提交注释,以前的历史记录都在。 ?
] [file-renamed] 四、代码提交 # 提交暂存区到仓库区 $ git commit -m [message] # 提交暂存区的指定文件到仓库区 $ git commit [file1]...-m [message] # 提交工作区自上次commit之后的变化,直接到仓库区 $ git commit -a # 提交时显示所有diff信息 $ git commit -v # 将add和commit...] # 显示某次提交发生变化的文件 $ git show --name-only [commit] # 显示某次提交时,某个文件的内容 $ git show [commit]:[filename] #...[file] # 恢复某个commit的指定文件到暂存区和工作区 $ git checkout [commit] [file] # 恢复暂存区的所有文件到工作区 $ git checkout . # 重置暂存区的指定文件...# 获取所有远程分支(不更新本地分支,另需merge) git fetch --prune # 获取所有原创分支并清除服务器上已删掉的分支
另外,还可以使用其他参数控制显示内容,这里不展开。...rebase 小结: rebase : 一连串的 cherry-pick。(移花接木) 3.3 reset reset,重置,将当前分支的状态(这里指工作区,暂存区,代码仓库)重置到指定的状态。...具体来看: git reset —hard 从参数名可以猜到,这个重置方式比较“强硬”,实际上就是,将当前分支,重置到与指定引用一样的状态,丢弃在这之后的提交,以及工作区和暂存区的提交。...未追踪的文件是不受影响的,PS:git clean 命令会清除掉未追踪的文件。 案例1 (@f/table)git reset —hard f/table~2 的含义?...当前在 f/table 分支,将其重置到 f/table~2 ,结果就是:丢弃掉 f/table 最新的两个提交。 案例2 将当前分支重置到远端最新 dev 的状态,怎么做?
ar 作者修订日期,按多久以前的方式显示 %cn 提交者(committer)的名字 %ce 提交者的电子邮件地址 %cd 提交日期 %cr 提交日期,按多久以前的方式显示 %s 提交说明 git log...上面的例子中,在checkout后,README.md文件恢复成了在修改之前(上次提交时)的样子,并且工作目录是干净的。...git checkout -- FILE命令按下面的逻辑运行: 如果该文件已经保存到暂存区,那么恢复到暂存区文件的状态。 如果该文件还没有保存到暂存区,那么恢复到上次提交时的状态。...--mixed:默认命令选项,即不写命令选项时执行此命令选项。仅仅重置暂存区(index)至给定提交,不重置工作目录。 --soft:暂存区与工作目录都不会被重置,仅仅把HEAD指向给定提交。...所以上例中的git reset --hard HEAD^将工作目录和暂存区全部重置到前一次提交,并且将HEAD指向前一次提交,后面的命令结果显示确实是这样。