Git 系列(四):在 Git 中进行版本回退

在这篇文章中,你将学到如何查看项目中的历史版本,如何进行版本回退,以及如何创建 Git 分支以便你可以大胆尝试而不会出现问题。

在你的 Git 项目的历史中,你的位置就像是摇滚专辑中的一个片段,由一个被称为 HEAD 的 标记来确定(如磁带录音机或录音播放器的播放头)。要在你的 Git 时间线上前后移动 HEAD ,需要使用 git checkout 命令。

git checkout 命令的使用方式有两种。最常见的用途是从一个以前的提交中恢复文件,你也可以整个倒回磁带,切换到另一个分支。

恢复一个文件

当你意识到一个本来很好文件被你完全改乱了。我们都这么干过:我们把文件放到一个地方,添加并提交,然后我们发现它还需要做点最后的调整,最后这个文件被搞得面目全非了。

要把它恢复到最后的完好状态,使用 git checkout 从最后的提交(即 HEAD)中恢复:


  1. $ git checkout HEAD filename

如果你碰巧提交了一个错误的版本,你需要找回更早的版本,使用 git log 查看你更早的提交,然后从合适的提交中找回它:


  1. $ git log --oneline
  2. 79a4e5f bad take
  3. f449007 The second commit
  4. 55df4c2 My great project, first commit.
  5. $ git checkout 55df4c2 filename

现在,以前的文件恢复到了你当前的位置。(任何时候你都可以用 git status 命令查看你的当前状态)因为这个文件改变了,你需要添加这个文件,再进行提交:


  1. $ git add filename
  2. $ git commit -m 'restoring filename from first commit.'

使用 git log 验证你所提交的:

$ git log --oneline
d512580 restoring filename from first commit
79a4e5f bad take
f449007 The second commit
55df4c2 My great project, first commit.

从本质上讲,你已经倒好了磁带并修复了坏的地方,所以你需要重新录制正确的。

回退时间线

恢复文件的另一种方式是回退整个 Git 项目。这里使用了分支的思想,这是另一种替代方法。

如果你要回到历史提交,你要将 Git HEAD 回退到以前的版本才行。这个例子将回到最初的提交处:

$ git log --oneline
d512580 restoring filename from first commit
79a4e5f bad take
f449007 The second commit
55df4c2 My great project, first commit.

$ git checkout 55df4c2

当你以这种方式倒回磁带,如果你按下录音键再次开始,就会丢失以前的工作。Git 默认假定你不想这样做,所以将 HEAD 从项目中分离出来,可以让你如所需的那样工作,而不会因为偶尔的记录而影响之后的工作。

如果你想看看以前的版本,想要重新做或者尝试不同的方法,那么安全一点的方式就是创建一个新的分支。可以将这个过程想象为尝试同一首歌曲的不同版本,或者创建一个混音的。原始的依然存在,关闭那个分支做你想做的版本吧。

就像记录到一个空白磁带一样,把你的 Git HEAD 指到一个新的分支处:

$ git checkout -b remix
Switched to a new branch 'remix'

现在你已经切换到了另一个分支,在你面前的是一个替代的干净工作区,准备开始工作吧。

也可以不用改变时间线来做同样的事情。也许你很想这么做,但切换到一个临时的工作区只是为了尝试一些疯狂的想法。这在工作中完全是可以接受的,请看:

$ git status
On branch master
nothing to commit, working directory clean

$ git checkout -b crazy_idea
Switched to a new branch 'crazy_idea'

现在你有一个干净的工作空间,在这里你可以完成一些奇怪的想法。一旦你完成了,可以保留你的改变,或者丢弃他们,并切换回你的主分支。

若要放弃你的想法,切换到你的主分支,假装新分支不存在:

$ git checkout master

想要继续使用你的疯狂的想法,需要把它们拉回到主分支,切换到主分支然后合并新分支到主分支:

$ git checkout master
$ git merge crazy_idea

git 的分支功能很强大,开发人员在克隆仓库后马上创建一个新分支是很常见的做法;这样,他们所有的工作都在自己的分支上,可以提交并合并到主分支。Git 是很灵活的,所以没有“正确”或“错误”的方式(甚至一个主分支也可以与其所属的远程仓库分离),但分支易于分离任务和提交贡献。不要太激动,你可以如你所愿的有很多的 Git 分支。完全自由。

远程协作

到目前为止你已经在自己舒适而私密的家中维护着一个 Git 仓库,但如何与其他人协同工作呢?

有好几种不同的方式来设置 Git 以便让多人可以同时在一个项目上工作,所以首先我们要克隆仓库,你可能已经从某人的 Git 服务器或 GitHub 主页,或在局域网中的共享存储上克隆了一个仓库。

工作在私人仓库下和共享仓库下唯一不同的是你需要把你的改变 push 到别人的仓库。我们把工作的仓库称之为本地local仓库,其他仓库称为远程remote仓库。

当你以读写的方式克隆一个仓库时,克隆的仓库会继承自被称为 origin 的远程库。你可以看看你的克隆仓库的远程仓库:


  1. $ git remote --verbose
  2. origin seth@example.com:~/myproject.Git (fetch)
  3. origin seth@example.com:~/myproject.Git (push)

有一个 origin 远程库非常有用,因为它有异地备份的功能,并允许其他人在该项目上工作。

如果克隆没有继承 origin 远程库,或者如果你选择以后再添加,可以使用 git remote 命令:


  1. $ git remote add seth@example.com:~/myproject.Git

如果你修改了文件,想把它们发到有读写权限的 origin 远程库,使用 git push。第一次推送改变,必须也发送分支信息。不直接在主分支上工作是一个很好的做法,除非你被要求这样做:


  1. $ git checkout -b seth-dev
  2. $ git add exciting-new-file.txt
  3. $ git commit -m 'first push to remote'
  4. $ git push -u origin HEAD

它会推送你当前的位置(HEAD)及其存在的分支到远程。当推送过一次后,以后每次推送可以不使用 -u 选项:


  1. $ git add another-file.txt
  2. $ git commit -m 'another push to remote'
  3. $ git push origin HEAD

合并分支

当你工作在一个 Git 仓库时,你可以合并任意测试分支到主分支。当团队协作时,你可能想在将它们合并到主分支之前检查他们的改变:


  1. $ git checkout contributor
  2. $ git pull
  3. $ less blah.txt ### 检查改变的文件
  4. $ git checkout master
  5. $ git merge contributor

如果你正在使用 GitHub 或 GitLab 以及类似的东西,这个过程是不同的。但克隆项目并把它作为你自己的仓库都是相似的。你可以在本地工作,将改变提交到你的 GitHub 或 GitLab 帐户,而不用其它人的许可,因为这些库是你自己的。

如果你想要让你克隆的仓库接受你的改变,需要创建了一个拉取请求pull request,它使用 Web 服务的后端发送补丁到真正的拥有者,并允许他们审查和拉取你的改变。

克隆一个项目通常是在 Web 服务端完成的,它和使用 Git 命令来管理项目是类似的,甚至推送的过程也是。然后它返回到 Web 服务打开一个拉取请求,工作就完成了。

原文发布时间为:2016-08-12

本文来自合作伙伴“Linux中国”

时间: 2024-10-21 08:51:01

Git 系列(四):在 Git 中进行版本回退的相关文章

【git学习四】git基础之git为项目打标签

1.背景           今天学习了下如何给项目打标签,为此项目的修改标记版本号,然后可以直接推送版本号到服务器上,方便了很多,而且便于对项目进行管理. 2.打标签                  1.查询已有标签,可以使用git tag命令,查询某个特定版本可以git tag -l 'v*' git tag         2.为版本创建标签 git tag -a v1.4 -m 'my version 1.4'      3.查看添加的标签,git show命令 git show  

git版本控制工具(二)----本地版本库的常用操作

[正文] 在上一章节中,我们学习了关于Git最基本的用法,包括安装Git.创建版本库,以及提交本地代码.本章节中将学习更多的使用技巧.即:Git版本控制工具(一)----git的安装及创建版本库 我们先要做好准备工作,将某个项目创建版本库,我这里就新建一个Android项目GitTest,创建一个版本库.打开Git Bash,进入到这个项目的根目录下,然后执行git init命令,如下图所示:   这样,准备工作就做好了.   一.忽略文件: 版本库已经创建好了,接下来我们需要提交项目中的代码,

《走进git时代系列三》详解部分git思想及SVN/GIT命令对比解析

之前写了一篇 走进git时代一之你该怎么玩? , 主要是对git的特性做了个引导, 用户还是需要自己找资料系统的去学习. 所以补充一篇分享,稍微详细一点解释一下svn和git的差异性, 以及日常工作的命令对比 . 帮助大家在学习git的道路上更加清晰. 目录 再谈SVN/GIT思想差别带来的影响 你需要知道的SVN/GIT命令操作 首先还是要强调一下 : 在开始学习 Git 的时候,请不要尝试把各种概念和其他版本控制系统(SVN,P4等)相比拟,否则容易混淆每个操作的实际意义. Git 在保存和

Git的纯命令操作,Install,Clone , Commit,Push,Pull,版本回退,撤销更新,分支的创建/切换/更新/提交/合并,代码冲突

Git的纯命令操作,Install,Clone , Commit,Push,Pull,版本回退,撤销更新,分支的创建/切换/更新/提交/合并,代码冲突 这篇是接着上篇分布式版本库--Windows下Git的环境部署以及在GitHub上开源自己的项目讲的,上篇主要是说用GUI来图形化界面操作,但是一般我们程序员也不会这么干,用命令又轻松又愉悦,所以,这里我就再开了一篇来专门说一下纯命令是怎么去操作的,但是要注意哦,其实廖雪峰老师的网站就是非常赞的学习资源哦! 廖雪峰老师:http://www.li

Git 系列(一):什么是 Git

欢迎阅读本系列关于如何使用 Git 版本控制系统的教程!通过本文的介绍,你将会了解到 Git 的用途及谁该使用 Git. 如果你刚步入开源的世界,你很有可能会遇到一些在 Git 上托管代码或者发布使用版本的开源软件.事实上,不管你知道与否,你都在使用基于 Git 进行版本管理的软件:Linux 内核(就算你没有在手机或者电脑上使用 Linux,你正在访问的网站也是运行在 Linux 系统上的),Firefox.Chrome 等其他很多项目都通过 Git 代码库和世界各地开发者共享他们的代码. 换

Git 系列(三):建立你的第一个 Git 仓库

现在是时候学习怎样创建你自己的 Git 仓库了,还有怎样增加文件和完成提交. 在本系列前面的文章中,你已经学习了怎样作为一个最终用户与 Git 进行交互:你就像一个漫无目的的流浪者一样偶然发现了一个开源项目网站,克隆了仓库,然后你就可以继续钻研它了.你知道了和 Git 进行交互并不像你想的那样困难,或许你只是需要被说服现在去使用 Git 完成你的工作罢了. 虽然 Git 确实是被许多重要软件选作版本控制工具,但是并不是仅能用于这些重要软件:它也能管理你购物清单(如果它们对你来说很重要的话,当然可

Git 系列(二):初步了解 Git

在这个系列的介绍篇中,我们学习到了谁应该使用 Git,以及 Git 是用来做什么的.今天,我们将学习如何克隆公共 Git 仓库,以及如何提取出独立的文件而不用克隆整个仓库. 由于 Git 如此流行,因而如果你能够至少熟悉一些基础的 Git 知识也能为你的生活带来很多便捷.如果你可以掌握 Git 基础(你可以的,我发誓!),那么你将能够下载任何你需要的东西,甚至还可能做一些贡献作为回馈.毕竟,那就是开源的精髓所在:你拥有获取你使用的软件代码的权利,拥有和他人分享的自由,以及只要你愿意就可以修改它的

Git系列(六):如何搭建你自己的Git服务器

现在我们将要学习如何搭建 git 服务器,如何编写自定义的 Git 钩子来在特定的事件触发相应的动作(例如通知),或者是发布你的代码到一个站点. 直到现在,我们主要讨论的还是以一个使用者的身份与 Git 进行交互.这篇文章中我将讨论 Git 的管理,并且设计一个灵活的 Git 框架.你可能会觉得这听起来是 "高阶 Git 技术" 或者 "只有狂热粉才能阅读"的一句委婉的说法,但是事实是这里面的每个任务都不需要很深的知识或者其他特殊的训练,就能基本理解 Git 的工作

git学习------>如何修改git已提交的记录中的Author和Email?

一.背景 最近搭建好GitLab后,准备陆陆续续的将之前在SVN仓库中保存的代码迁移到GitLab上,昨天顺利将三个Android组件的代码迁移到GitLab后,其他同事发现迁移是成功了,但是pull下来命令后查看git log 发现所有人的有些都配置成了我的邮箱,尴尬啊. GitLab上面全部变成了我的提交记录,尴尬. 二.原因分析 下面具体分析下为什么产生这个的原因. 具体原因是因为再做SVN–>Git迁移准备的时候,第一步要建议SVN用户到Git用户的映射文件.而这个映射文件最终我将所有用