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 包管理器。
注册/登录 InfoQ 发表评论