git查看历史版本

Posted 2023-04-27

参考技术A

一、git 获取历史版本的几种方式

我们简单的描述一个例子：a）初始化操作有两个文件file1.txt和file2.txt1， 初始化的时候就有这两个文件操作：git initgit statusgit add .git mit -m “init version”2， 在master分支上修改了file1.txt，并提交操作：（修改file1.txt）git add file1.txtgit mit -m “change file1”3， 然后新建分支banana，并切换到banana分支上操作：git branch bananagit checkout banana4， 修改file1.txt和file2.txt，并提交。

操作：（修改file1.txt和file2.txt）git add file1.txt file2.txtgit mit -m “change by banana”这个时候，我们可以输入 gitk，查看一下当前的版本情况。如下图：git-0015， 然后，切换到master分支上，修改file2.txt，并提交。

操作：git checkout master（修改file2.txt）git add file2.txtgit mit -m “change by master”输入gitk，查看当前版本情况，如下图：git-002b）发现问题需要查看历史版本我们现在发现当前的版本有点问题，还不能提交到版本库。1，我们需要从git mit中返回.则输入：git reset --soft HEAD^解释一下，HEAD是当前分支的最新版本。

^表示父节点。当前节点的父节点，就是上一次提交的版本。

也就是标记为“change file1”的版本。问为什么不是”change by banana”这个版本呢？不同的分支哦。”

change by banana”是banana分支的最新代码，和master分支不同的。这个时候输入git status看看，是不是显示file2.txt修改了没有提交呢。

2，我们需要从git add中返回再仔细查看之后，我们发现file2.txt真的写错了，需要返回到git add之前的状态。输入：git reset -q file2.txt这个时候，file2.txt就回到了解放前了。

用git status查看一下，file2.txt是”change not staged for mit”状态。3，回到没有做过的情况我们最终确定，最后一次修改的file2.txt是无用的代码，我们需要废弃掉。

注意，这个操作不能恢复的哦。git reset --hard这个命令，不能指定具体的文件。

是把当前的修改全部清除，恢复到最后一次提交的版本。这个时候，用gitk查看一下：git-003已经彻底回复到了“change file 1”的版本了。

4，直接回复到某个版本我们现在切换到banana分支。git checkout banana然后用gitk看一下。

可以看出，我们之前的操作，对banana分支一点影响也没有。现在我们需要把banana分支回复到初始状态，但是当前的改动的代码还是需要留着。

我们可以看，init版本是当前版本的父节点的父节点。我们可以这么操作：git reset --soft HEAD^^然后用gitk看一下：git-004最近的版本已经变成了init version了。

所有的改动都是add未提交状态。5，得到当前最新代码最后。

我们把file1.txt和file2.txt都删掉。我们需要从版本库中取得当前最新的代码。

很简单：git checkout master如果是要banana分支的最新代码，则：git checkout banana以上的操作，我们知道了如何查看版本分支，和如何回复到以前的版本。

二、windows下git怎么查看提交历史

1.查看Git日志：

命令：git log 默认不加参数，git日志会按照最新的日期从上往下显示 参数：-p 显示版本间的代码差异

-数字 显示部分的提交

-哈希值 显示指定的版本

2.指定查找范围：

--since="5 hours" 显示最近5小时内的提交 --since="5 hours" -1 显示5小时内的最后一个提交 --before 用法和--since的用法差不多，显示的是在某个时间点之前的提交 版本1..版本2 说明：版本1之后到版本2的所有提交，版本2可以用 HEAD（要注意大写）表示当前的最新版本 版本^ 回溯一个版本 注意： 在windows下要加双引号"版本^" ~N： 回溯N个版本

3.查看指定版本之间的差异

git diff 版本号 说明：当前目录树和对应版本号的差异 git diff --stat 说明：统计对应改动的代码量

4.撤销修改

4.1增补修改（只能用于针对最后一个提交）

git mit -C HEAD -a --amend

4.2反转提交

创建一个新的反向的提交来抵消原来的提交

git revert -n HEAD 反转当前版本库最新的提交并且缓存起来。但是不提交

4.3复位

git reset --soft 缓存因复位带来的差异但是不提交，也就是复位到上一个提交前的状态 git reset --hard 同时删除提交 例子：git reset --hard HEAD^ 复位到HEAD之前的那个版本

5重新改写历史记录

什么时候需要改写历史记录？

给历史记录重新排序

多个提交合并成一个提交

一个提交分解成多个提交

git rebase -i HEAD~3

本质上利用的是变基操作，定位到你想变化的范围之前。然后进入编辑器去修改你想修改的部分。完成之后再回到当前的末梢。

三、windows下git怎么查看提交历史

给历史记录重新排序多个提交合并成一个提交一个提交分解成多个提交git rebase -i HEAD~3本质上利用的是变基操作，定位到你想变化的范围之前.指定查找范围：--since="5 hours"。

然后进入编辑器去修改你想修改的部分：版本1之后到版本2的所有提交，版本2可以用 HEAD（要注意大写）表示当前的最新版本 版本^ 回溯一个版本 注意： 在windows下要加双引号":git log 默认不加参数，git日志会按照最新的日期从上往下显示 参数； -1 显示5小时内的最后一个提交 --before 用法和--since的用法差不多：-p 显示版本间的代码差异-数字 显示部分的提交-哈希值 显示指定的版本2..版本2 说明；版本^" ~N： 回溯N个版本3； 显示最近5小时内的提交 --since="5 hours".3复位git reset --soft 缓存因复位带来的差异但是不提交，也就是复位到上一个提交前的状态 git reset --hard 同时删除提交 例子：git reset --hard HEAD^ 复位到HEAD之前的那个版本5重新改写历史记录什么时候需要改写历史记录，显示的是在某个时间点之前的提交 版本1.查看指定版本之间的差异git diff 版本号 说明：当前目录树和对应版本号的差异 git diff --stat 说明：统计对应改动的代码量4.撤销修改4.1增补修改（只能用于针对最后一个提交）git mit -C HEAD -a --amend4.2反转提交创建一个新的反向的提交来抵消原来的提交git revert -n HEAD 反转当前版本库最新的提交并且缓存起来。但是不提交41.查看Git日志：命令。

四、怎么查看ubuntu git版本

git查看提交历史

这是git中使用平率非常高的一个操作，git中查看提交历史的功能也非常强大，提供各种筛选和输出格式定制功能。

最简单的，运行git log命令，你将看到一个详细的提交日志：

git-log

# 当然也可以只查看某个版本

$ git log fd0a1b2

信息内容都很好理解，重点说说第一行mit后这个40个字符的字符串，这是该次提交的对应的SHA-1值，在git中，会对提交（mit）、文件（blob）、目录（tree）、标签（tag）生成一个唯一的SHA-1值，git就是基于此来得知文件或目录的改动，因为这四类对象计算得到的SHA-1值都是唯一的，同时你也可以直接使用SHA-1值来指代相应的对象。比如：

$ git show bdd3996

# 查看某个版本下具体某个文件

$ git show bdd3996 README

git log还有很多命令选项来定制历史记录

选项 说明

-(n) 仅显示最近的 n 条提交

–since，–after 仅显示指定时间之后的提交

–until，–before 仅显示指定时间之前的提交

–author 仅显示指定作者相关的提交

–mitter 仅显示指定提交者相关的提交

–reverse 按时间倒序显示

-p 按补丁格式显示每个更新之间的差异

–stat 显示每次更新的文件修改统计信息

–shortstat 只显示 –stat 中最后的行数修改添加移除统计

–name-only 仅在提交信息后显示已修改的文件清单

–name-status 显示新增、修改、删除的文件清单

–abbrev-mit 仅显示 SHA-1 的前几个字符，而非所有的 40 个字符

–relative-date 使用较短的相对时间显示（比如，“2 weeks ago”）

–graph 显示 ASCII 图形表示的分支合并历史

五、Git怎么还原上一个版本

第一步： git log 查看之前的mit的id，找到想要还原的版本第二步： git reset --hard 44bd896bb726be3d3815f1f25d738a9cd402a477 还原到之前的某个版本第三步： git push -f origin master 强制push到远程 前两步在eclipse中也可操作： team --> show in hostory 找到想还原的版本 然后再强制push (git push -f origin master)。

六、如何用 Git 将代码恢复到一个历史的版本

有些时候，在一些特殊情况下，我们需要将代码恢复到一个历史的提交版本上。

而这个历史提交版本，离最新的提交已经比较久远了。比如，我希望将如下的仓库的提交，恢复到上上上上次提交。

当然，我可以一次一次的 revert，但是有没有更快更简单的办法呢？暴力的方式如果你的仓库是自己在用（不影响别人），那么你可以使用 git reset --hard 来恢复到指定的提交，再用 git push -f 来强制更新远程的分支指针。为了保证万一需要找回历史提交，我们可以先打一个 tag 来备份。

对于刚刚的例子，需要执行的命令就是：// 备份当前的分支到 backup_mitgit tag backup_mitgit push origin backup_mit// 重置 source 分支git reset --hard 23801b2// 强制 push 更新远程分支git push origin source -f温和的方式如果你的仓库是多人在协作，那么你这么操作会使用别人本地的代码库混乱，所以只能建一个新的提交，这个新的提交中把想取消的提交都 revert 掉，那么具体应该如何做呢？方法如下：首先，和刚刚一样，用 git reset --hard 23801b2 将代码切换到目标提交的 id。接下来，用 git reset --soft origin/source 命令，将当前代码切换回最新的提交。

执行完上面两步后，你的仓库还是最新的提交，但是工作区变成了历史的提交内容，这个时候用 git add 和 git mit 即可。最终完成的效果如下：不过经过念茜的提醒，该方法需要保证 reset 的时候没有别人做新的提交，如果有的话，会一并把别人的提交也撤销了。

所以还是挺危险的，慎用。虽然用到的时候很少，但是理解它的原理有助于大家理解 Git 的工作区，暂存区和版本库的各种指针操作的意义，希望对大家有用。

七、git怎么查询当前分支的版本号

#git reflog git log --pretty =oneline结果如下：69e1506ad9fed9771b9f7d1e478ac2ff05fc3604 Add git user profile functions for prompt displayc4582777fc50162d8b433cabad34f629b0ea9b98 Merge pull request #4957 from TorrentKatten/mastere8a9d0ee1a97033fb4aa371263889b77200b6d62 localization support for clock in candy themec3b3de5f29b72b45393b62d794450ad3a72703a8 Merge pull request #4956 from RobLoach/asdf616ac67924212df2f75139c94ca323f13f249dc6 Add \'asdf\' plugin。

git入门(1.历史)

git入门(1.历史)

git入门(2.基础)

git入门(3.文件操作)

git入门(4.提交与历史)

git入门(5.分支)

git入门(6.repo)

版本控制

　　版本控制是什么已不用在说了，就是记录我们对文件、目录或工程等的修改历史，方便查看更改历史，备份以便恢复以前的版本，多人协作。。。

一、原始版本控制

　　最原始的版本控制是纯手工的版本控制：修改文件，保存文件副本。有时候偷懒省事，保存副本时命名比较随意，时间长了就不知道哪个是新的，哪个是老的了，即使知道新旧，可能也不知道每个版本是什么内容，相对上一版作了什么修改了，当几个版本过去后，很可能就是下面的样子了：

　　 

二、本地版本控制

　　手工管理比较麻烦且混乱，所以出现了本地版本控制系统，记录文件每次的更新，可以对每个版本做一个快照，或是记录补丁文件。比如RCS。

　　 

三、集中版本控制

　　但是本地版本控制系统偏向于个人使用，或者多个使用的人必须要使用相同的设备，如果需要多人协作就不好办了，于是，集中化的版本控制系统（ Centralized Version Control Systems，简称 CVCS ）应运而生，比如Subversion，Perforce。

　　在CVCS中，所有的版本数据都保存在服务器上，一起工作的人从服务器上同步更新或上传自己的修改。

 　　 

　　但是，所有的版本数据都存在服务器上，用户的本地设备就只有自己以前所同步的版本，如果不连网的话，用户就看不到历史版本，也无法切换版本验证问题，或在不同分支工作。。

　　而且，所有数据都保存在单一的服务器上，有很大的风险这个服务器会损坏，这样就会丢失所有的数据，当然可以定期备份。

四、分布式版本控制

　　针对CVCS的以上缺点，出现了分布式版本控制系统( Distributed Version Control System,简称 DVCS )，如GIT，Mercurial。

　　DVCS不是复制指定版本的快照，而是把所有的版本信息仓库全部同步到本地，这样就可以在本地查看所有版本历史，可以离线在本地提交，只需在连网时push到相应的服务器或其他用户那里。由于每个用户那里保存的都是所有的版本数据，所以，只要有一个用户的设备没有问题就可以恢复所有的数据。

　　当然，这增加了本地存储空间的占用。

--------------------------------------------附件是全部的内容--------------------------------------------------------

版本控制.doc

----------------------------------------------转载自----------------------------------------------------------------------

http://www.cnblogs.com/angeldevil/p/3238470.html