《Git in Practice》作者访谈：关于Git的八个问题

《Git实战指南》

最新推荐文章于 2025-03-29 09:19:20 发布

糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖

最新推荐文章于 2025-03-29 09:19:20 发布

阅读量68

点赞数

CC 4.0 BY-SA版权

本文链接：https://blog.youkuaiyun.com/cpongo4/article/details/89103247

Mike McQuaid的著作《Git in Pratice》是一份具有动手实践性的指导，它从实践性的角度介绍了Git，提供了超过60种在操作Git库时会使用到的技巧和命令，并且为有经验的用户提供了一些高级技巧和工作流。

本书共分为四个部分，让高级用户可以随意跳到感兴趣的章节，而新手可以按顺序完整阅读，并且最终理解如何在Git库上进行工作。

本书的第一部分对Git进行了基本的介绍，从命令行的角度（以及通过GUI的方式）介绍了各种命令是如何工作的，同时介绍了如何搭建Git库，并且如何在远程Git库、例如在GitHub上进行工作。没有体验过Git的读者在读过第一部分后，能够获得基本的知识，这将成为阅读之后的章节的坚实基础。

第二部分详细介绍了Git库内部的工作原理，以及历史和恢复等操作的意义。这些的内容涵盖了merge、stash、rebase和reflog等等，同时也介绍了Git如何管理库历史的方式。

第三部分为更高级的Git命令提供了一份概述，包括如何对Git进行配置以提供一个更有用的shell、各种有用的配置选项，以及别名（alias）的创建和对子模块的支持。同时还讲到了如何将一个SVN库升级为Git库，以及如何通过UI和命令行的方式处理GitHub中的pull request。

最后一个部分讨论了Git的工作流，这里的讨论引用了Mike在Homebrew和CMake这两个项目中的经验，以及每种工作流的优点和缺点。采用持续部署/单一扁平化的历史，还是采用合并网络，这是由每个项目各自的工作实践所决定的。Mike将这些工作流与Git Flow、GitHub Flow以及他称之为“Mike Flow”的流程进行了对比。这一部分的最后是对不同类型的团队和项目所采用的各种工作流类型及作者的推荐。

本书包含了许多动手实验性的技巧和示例，并且以一种便于随时查找历史的方式提供给读者。

InfoQ有幸与McQuaid进行了一次访谈，谈论了有关本书的多个话题。访谈的第一个问题是：为什么Git这种版本控制系统只能在命令行中使用？

\
McQuaid：Git的主要使用方式是作用命令行工具使用，我在本书中主要专注于这一界面。而且我认为，如果你希望使用Git实现一些高级操作，或者本身是一位高级软件工程师，那么它是值得你学习的。如果你不是一位软件工程师，那么我大概会为用户推荐GUI应用，例如GitHub for Mac、GitHub for Windows、GitX-dev、GitHub网站（在该网站上能够创建分支或是提交代码），或者是你所使用的IDE（例如Visual Studio或Eclipse）上的各种插件。
\

InfoQ：Git是一种分散式的版本控制系统；这是否意味着在Git中不存在中央式的库呢？

\
McQuaid：Git本身可以作为一种仅用于本地的版本控制系统，它能够和其它库不产生任何交互。此外，某个Git库也能够对远程库进行fetch/pull/clone操作，或将代码push至其它远程库。这些库之间不存在耦合性，这也是Git成为分散式版本控制系统的原因。但Git也是能够以一种中央式的方式进行使用的。
\\
如果你在一个团队中与其它工程师一起合作，并且每个人都有对GitHub上某个私有库的写入权限，那么通常来说你只拥有一个远程库（在默认情况下命名为“origin”），并且以一种中央式库的方式对该库进行push和pull的操作。
\

InfoQ：为了使用Git，是否有必要理解Git在底层是如何保存库的内容的呢？

\
McQuaid：当然不是必须的。虽然我本人写了这本《Git In Practice》，但我都还没有真正理解Git是如何保存库内容的！在《Git In Practice》这本书中，我是有意避免告诉读者这些内容的。关于Git保存数据的某些方面知识（例如：理解分支和标签只是指针）将有助于理解Git中的某些更奇特的信息，例如像“分离HEAD指针”这样的信息。但即使如此，这些内容也不是必须掌握的。
\

InfoQ：对于那些打算将Subversion迁移至Git库的用户，你有些什么建议？

\
McQuaid：不要尝试将两者的概念进行过于密切的映射。它们本身就是不同的工具，各自具有不同的长处、短处和界面。可以考虑使用git-svn或GitHub库的Subversion后台工具，以保证你能够逐步地测试迁移的效果，并且让不同的组在不同的时间进行迁移工作。确保你的知识不仅仅停留在Git的基础知识的层面上，也不要害怕进行重写（本地）历史这样的操作，这样你才能够最大程度地利用好这一项工具。
\

InfoQ：对于不熟悉Git的用户来说，他们会担心是否会造成重写或丢失历史信息，这种担心是有道理的吗？

\
McQuaid：在Git中重写历史是有可能的（我甚至认为是有道理的），不过丢失历史信息基本上是不可能的。每次你在Git中提交代码的时候，会根据代码内容和元数据生成一个唯一的引用。这些引用是不会重复的，并且是永远有效的，即使在重写历史后也是一样，直到被销毁后才会丢失。提交只有在从所有的分支中移除超过90天之后才会被销毁，在那之前，你可以使用“git reflog”命令查看历史重写的过程与时间，并且恢复历史中的任意一个旧版本。
\

InfoQ：对于那些需要管理多个发布版本，而不是对单一版本进行持续部署的项目来说，Git是否适用呢？

\
McQuaid：是的！Git对于分支与标签的支持良好，并且比起其它多数版本控制系统来说，在Git中创建分支和切换分支的速度要快得多。
\

InfoQ：在开发团队中常用的Git工作流模式有哪些？

\
McQuaid：我所知的两种最常见的工作流是GitHub Flow和Git Flow（或者是他们的修改版本）。GitHub Flow专注于以最快的速度从master进行分支，提交pull request，以及合并回master分支的操作。而Git Flow的流程更为复杂，我在这里不打算深入讨论它的细节，只是简单地说几条：它在任意分支提交至生产环境或某个稳定的分布版本时提供了多种检查。我个人觉得，Git Flow有些过于复杂了，这也是我推出了一个我（愚蠢地）称之为Mike Flow的个人版本的工作流。
\

InfoQ：你能描述一下Mike Flow工作方式，以及为什么你觉得它对于读者来说能够起到作用的原因吗？

\
McQuaid：我认为Mike Flow是以上两种工作流的一个最佳的结合方式。它本质上是一种GitHub Flow的修改版本，但推荐你进行更多的rebase操作（一种重写历史的方式），并且只有在稳定的发布成为必须条件的情况下才会创建长期的分支。在《Git in Practice》一书中，我介绍了有关Mike Flow的更多细节信息，并将它与GitHub Flow和Git Flow进行了对比。
\

《Git in Practice》是由Manning出版的图书。在manning.com使用折扣码infoqgip，可以以六折的价格购买《Git in Practice》。

关于本书作者

Mike McQuaid是GitHub是一位软件工程师。除了本职工作之外，他还会在技术会议上进行Git方面的演讲，也会为人们提供Git方面的培训。他在基于Git的开源软件方面做出了广泛的贡献，包括Qt 和Linux kernel，同时也是基于Git的Homebrew项目的维护者之一，该项目是一个很流行的OSX包管理器。