Git-和-Github-入门指南-一-

Git 和 Github 入门指南（一）

原文：Beginning DevOps on AWS for iOS Development

协议：CC BY-NC-SA 4.0

一、版本控制系统

这是我们进入版本控制系统(VCSs)的第一步。在本章结束时，你应该知道版本控制、Git 及其历史。主要目的是了解在什么情况下需要版本控制，以及为什么 Git 是一个安全的选择。

什么是版本控制？

顾名思义，版本控制是关于一个项目的多个版本的管理。要管理版本，必须跟踪项目中文件的每次更改(添加、编辑或删除)。版本控制记录对一个文件(或一组文件)所做的每次更改，并提供一种撤消或回滚每次更改的方法。

为了有效的版本控制，你必须使用被称为版本控制系统的工具。它们帮助您在更改之间导航，并在出现问题时让您快速返回到以前的版本。

使用版本控制的一个最重要的优势是团队合作。当不止一个人对一个项目做出贡献时，跟踪变更就变成了一场噩梦，并且它大大增加了覆盖另一个人的变更的可能性。有了版本控制，多人可以在他们的项目副本上工作(称为分支),并且只有当他们(或者其他团队成员)对工作满意时，才将那些变更合并到主项目中。

注意

这本书是从开发人员的角度写的，但书中的一切都适用于任何文本文件，而不仅仅是代码。版本控制系统甚至可以跟踪对图像或 Photoshop 文件等许多非文本文件的更改。

你为什么需要一个？

你曾经做过一个文本项目或者一个需要你回忆对每个文件所做的具体修改的代码吗？如果是，您是如何管理和控制每个版本的？也许你试图复制这些文件，并用“审阅”、“修复”或“最终”这样的后缀来重命名它们？图 1-1 显示了那种版本控制。

图 1-1

后缀为“最终版”、“最终版(副本)”和“已审核”的 Gimp 文件

图中显示了许多人处理文件更改的方式。如你所见，这有可能很快失控。很容易忘记哪个文件是哪个文件，以及它们之间发生了什么变化。

要跟踪版本，一个想法是压缩文件并在文件名后添加时间戳，以便版本按照创建日期排列。图 1-2 显示了那种版本跟踪。

图 1-2

按日期排序的压缩版本文件

图 1-2 所示的解决方案似乎是完美的系统，直到你意识到即使版本被跟踪，也没有办法知道每个版本的内容和描述是什么。

为了补救这种情况，一些开发人员使用如图 1-3 所示的解决方案，即将每个版本的变更摘要放在一个单独的文件中。

图 1-3

跟踪每个版本的独立文件

如图 1-3 所示，项目文件夹附带了一个单独的文件，其中简要描述了所做的更改。还要注意许多包含项目早期版本的压缩文件。

应该可以了，对吧？不完全是，你仍然需要一种方法来比较每个版本和每个文件的变化。在那个系统中没有办法做到这一点；你只需要记住你所做的一切。如果项目越来越大，每个版本的文件夹都会越来越大。

当另一个开发者或作者加入你的团队时会发生什么？你会用电子邮件互相发送你编辑过的文件或版本吗？还是在同一个远程文件夹上工作？在最后一种情况下，您如何知道谁在处理哪个文件以及什么发生了变化？

最后，你有没有觉得有必要在不破坏过程中的一切的情况下，撤销几年前做出的改变？一个无限全能的 ctrl-z？

所有这些问题都可以通过使用版本控制系统或 VCS 来解决。VCS 跟踪您对项目的每个文件所做的每个更改，并提供一种简单的方法来比较和回滚这些更改。项目的每个版本还附有对所做更改的描述，以及新文件或编辑过的文件的列表。当更多的人加入这个项目时，VCS 可以准确地显示谁在特定的时间编辑了特定的文件。所有这些都让你为你的项目赢得了宝贵的时间，因为你可以专注于写作，而不是花时间跟踪每个变化。图 1-4 显示了一个由 Git 管理的版本化项目。

图 1-4

Git 版本化的项目

如图 1-4 所示，一个版本化的项目结合了我们在本章尝试的所有解决方案。有变更描述、团队合作和编辑日期。

让我们了解更多关于版本控制系统的信息。

有哪些选择？

版本控制系统有很多种，每种都有自己的优点和缺点。VCS 可以是本地的、集中式的或分布式的。

本地版本控制系统

这些是为管理源代码而创建的第一批 VCS。他们通过跟踪对本地存储的单个数据库中的文件所做的更改来工作。这意味着所有的更改都保存在一台计算机中，如果出现问题，所有的工作都会丢失。这也意味着与团队合作是不可能的。

最受欢迎的本地 VCS 之一是源代码控制系统或 SCCS，它是免费的，但不公开源代码。由美国电话电报公司开发，在 20 世纪 70 年代被广泛使用，直到修订版控制系统(RCS)发布。RCS 比 SCCS 更受欢迎，因为它是开源的、跨平台的，而且更有效。RCS 于 1982 年发布，目前由 GNU 项目维护。这两个本地 VCS 的缺点之一是它们一次只能处理一个文件；他们无法跟踪整个项目。

为了帮助你想象它是如何工作的，这里的图 1-5 展示了一个简单的本地 VCS。

图 1-5

本地 VCS 是如何工作的

如图 1-5 所示，所有东西都在用户的电脑上，只有一个文件被跟踪。版本控制存储在由本地 VCS 管理的数据库中。

集中式版本控制系统

集中式 VCS (CVCS)的工作方式是将变更历史存储在客户机(作者)可以连接的单一服务器上。这提供了一种与团队合作的方式，也提供了一种监控项目总体进度的方式。它们仍然很受欢迎，因为这个概念非常简单，很容易安装。

主要的问题是，就像当地的 VCS 一样，一个服务器错误会让团队失去所有的工作。还需要网络连接，因为主项目存储在远程服务器上。

你可以在图 1-6 中看到它是如何工作的。

图 1-6

中央集权的 VCS 是如何运作的

图 1-6 显示了集中式 VCS 的工作方式类似于本地 VCS，但是数据库存储在远程服务器上。

使用集中式 VCS 的团队面临的主要问题是，一旦某个文件被某人使用，该文件就会被锁定，其他团队成员就无法对其进行操作。因此，他们不得不相互协调来修改单个文件。这造成了开发中的许多延迟，并且通常是贡献者的许多挫折的来源。团队成员越多，问题就越多。

为了解决本地 VCS 的问题，并行版本系统(CVS)被开发出来。它是开源的，可以跟踪多组文件，而不是单个文件。许多用户也可以同时处理同一个文件，因此名称中有“并发”一词。所有的历史都存储在远程存储库中，用户可以通过签出服务器来跟上变化，这意味着将远程数据库的内容复制到他们的本地计算机上。

Apache Subversion 或 SVN 是在 2000 年开发的，可以做 CVS 能做的一切，还有一个好处:它可以跟踪非文本文件。SVN 的主要优势之一是，它不是像以前的 VCS 那样跟踪一组文件，而是跟踪整个项目。所以，它本质上是跟踪目录而不是文件。这意味着重命名、添加和删除也会被跟踪。这使得 SVN，连同它的开源，成为一个非常受欢迎的 very 至今仍被广泛使用。

分布式版本控制系统

分布式 VCS 的工作方式与集中式 VCS 几乎相同，但有一个很大的区别:没有保存所有历史的主服务器。每个客户端都有一个存储库的副本(以及更改历史)，而不是签出单个服务器。

这大大降低了丢失一切的可能性，因为每个客户都有一个项目的克隆。对于分布式 VCS，拥有“主服务器”的概念变得模糊，因为每个客户端本质上都拥有自己存储库中的所有权力。这极大地鼓励了开源社区中“分叉”的概念。分叉是克隆一个存储库的行为，以进行您自己的更改，并对项目进行不同的处理。分叉的主要好处是，如果您认为合适的话，您还可以从其他存储库中提取变更(其他人也可以对您的变更做同样的事情)。

分布式版本控制系统通常比其他类型的 VCS 更快，因为它不需要通过网络访问远程服务器。几乎所有的事情都在本地完成。它的工作方式也略有不同:它不是跟踪版本之间的变化，而是将所有变化作为“补丁”来跟踪这意味着这些补丁可以在存储库之间自由交换，因此没有“主”存储库需要跟上。

图 1-7 显示了分布式 VCS 的工作原理。

图 1-7

分布式 VCS 如何工作

注意

通过查看图 1-7 ，很容易得出这样的结论:有一个主服务器是用户一直关注的。但分布式 VCS 并非如此，它只是许多开发人员为了获得更好的工作流而遵循的惯例。

BitKeeper SCM 是 2000 年发布的专有分布式 VCS，像 20 世纪 70 年代的 SCCS 一样，是闭源的。它有一个免费的“社区版本”,缺少 BitKeeper SCM 的许多大功能，但因为它是第一个分布式 VCS 之一，所以即使在开源社区中也非常受欢迎。BitKeeper 的这种受欢迎程度对 Git 的创建起到了很大的作用。它现在是一个开源软件，其源代码于 2016 年在 Apache 许可下发布。可以在 www.bitkeeper.org/ 上找到当前的 BitKeeper 项目；发展慢下来了，但还是有社群在贡献。

Git 是什么？

还记得上一节提到的专有分布式版本控制系统 BitKeeper SCM 吗？嗯，Linux 内核开发人员使用它进行开发。使用它的决定被广泛认为是一个糟糕的举动，使许多人不高兴。他们的担心在 2005 年得到了证实，当时 BitKeeper SCM 不再免费。由于它是闭源的，开发者失去了他们最喜欢的版本控制系统。这个社区(由 Linus Torvalds 领导)不得不寻找另一个 VCS，由于没有替代方案，他们决定自己创造一个。于是，Git 诞生了。

因为 Git 是用来取代 BitKeeper SCM 的，所以它的工作原理基本相同，只是做了一些调整。像 BitKeeper SCM 一样，Git 是一个分布式版本控制系统，但是它速度更快，并且更适合大型项目。Git 社区非常活跃，有很多贡献者参与了它的开发；你可以在 https://git-scm.com/ 上找到更多关于 Git 的信息。Git 的特性及其工作原理将在本节稍后解释。

Git 能做什么？

还记得我们在本章开始时试图解决的那些问题吗？嗯，Git 可以全部解决。它甚至可以解决你以前不知道的问题！

首先，它非常适合跟踪更改。你可以

• 在不同版本之间来回切换

• 查看这些版本之间的差异

• 检查文件的更改历史

• 标记特定版本以便快速参考

Git 也是团队合作的一个很好的工具。你可以

• 在存储库之间交换“变更集”

• 查看其他人所做的更改

Git 的主要特征之一是它的分支系统。一个分支是一个项目的拷贝，你可以在不弄乱存储库的情况下工作。这个概念已经存在一段时间了，但是有了 Git，它会更快更有效。分支还伴随着合并，合并是将分支中完成的变更集复制回源的行为。通常，您创建一个分支来创建或测试一个新的特性，当您对工作满意时，将该分支合并回来。

还有一个你可能会经常用到的简单概念:藏东西。隐藏是安全地把你当前的编辑放在一边的行为，这样你就有一个干净的环境去做一些完全不同的东西。当你尝试或测试一个特性，但需要优先开发一个新特性时，你可能想使用 stashing。所以，你把你的修改藏起来，开始写那个特性。完成后，您可以取回所做的更改，并将其应用到当前的工作环境中。

作为开胃菜，下面是您将在本书中学习的一些 Git 命令:

$ git init     # Initialize a new git database

$ git clone    # Copy an existing database

$ git status   # Check the status of the local project

$ git diff     # Review the changes done to the project

$ git add      # Tell Git to track a changed file

$ git commit   # Save the current state of the project to database

$ git push     # Copy the local database to a remote server

$ git pull     # Copy a remote database to a local machine

$ git log      # Check the history of the project

$ git branch   # List, create or delete branches

$ git merge    # Merge the history of two branches together

$ git stash    # Keep the current changes stashed away to be used later

如您所见，这些命令非常简单明了。不要担心把它们都记在心里；当我们适当地开始学习时，你将一个一个地记住它们。你不会一直使用它们，你会经常使用 git add 和 git commit。您将了解每个命令，但我们将重点关注您可能在专业设置中使用的命令。但在此之前，我们先来看看 Git 的内部工作原理。

Git 是如何工作的？

与许多版本控制系统不同，Git 处理快照，而不是差异。这意味着它不跟踪文件的两个版本之间的差异，而是拍摄项目的当前状态。

这就是为什么 Git 与其他分布式 VCS 相比非常快；这也是为什么在版本和分支之间切换如此快速和容易。

还记得集中式版本控制系统是如何工作的吗？嗯，Git 是完全相反的。你不需要与中央服务器通信来完成工作。由于 Git 是一个分布式 VCS，每个用户都有自己完整的存储库，有自己的历史和变更集。因此，除了共享补丁或变更集之外，一切都在本地完成。如前所述，不需要中央服务器；但是许多开发人员使用一个作为惯例，因为这样更容易工作。

说到补丁共享，Git 怎么知道哪些变更集是谁的？当 Git 拍摄快照时，它会对快照执行校验和检查；因此，通过比较校验和，它知道哪些文件发生了变化。这就是为什么 Git 可以很容易地跟踪文件和目录之间的变化，并且它还检查任何文件损坏。

Git 的主要特点是它的“三态”系统。这些状态是工作目录、临时区域和 git 目录:

• 工作目录就是您正在处理的当前快照。

• 临时区域是修改后的文件在其当前版本中被标记的地方，准备存储在数据库中。

• git 目录是存储历史的数据库。

因此，基本上 Git 的工作方式如下:修改文件，将想要包含在快照中的每个文件添加到暂存区(git add)，然后获取快照并将它们添加到数据库(git commit)。对于术语，我们将添加到暂存区域的修改文件称为“暂存”，将添加到数据库的文件称为“提交”因此，文件从“修改”到“暂存”再到“提交”

典型的 Git 工作流程是怎样的？

为了帮助您形象化我们在本节中讨论的所有内容，这里有一个使用 Git 的典型工作流的小演示。如果你现在还不明白所有的事情，不要担心；接下来的几章将会帮助你设置好。

这是你第一天工作。您的任务是将您的名字添加到现有的项目描述文件中。因为这是你的第一天，一个高级开发人员会在那里检查你的代码。

你应该做的第一件事是获得项目的源代码。向您的经理询问存储代码的服务器。对于这个演示，服务器是 GitHub，这意味着 Git 数据库存储在 GitHub 托管的远程服务器上，您可以通过 URL 或直接在 GitHub 网站上访问它。这里，我们将使用 clone 命令来获取数据库，但是您也可以从 GitHub 网站下载项目。您将获得一个 zip 文件，其中包含和项目文件及其所有历史。

因此，您可以使用“clone”命令克隆存储库以获得源代码。

git clone https://github.com/mariot/thebestwebsite.git

Git 然后在您工作的当前目录中下载一个存储库的副本。之后，您可以进入新目录并检查其内容，如图 1-8 所示。

图 1-8

将显示存储库的内容

如果你想检查最近对项目所做的修改，你可以使用“日志”命令来显示历史。图 1-9 显示了一个例子。

图 1-9

典型的 Git 历史日志

很好！现在你应该创建一个新的分支来工作，这样你就不会弄乱这个项目。您可以使用“branch”命令创建一个新的分支，并使用“checkout”命令将其签出。

git branch add-new-dev-name-to-readme
git checkout add-new-dev-name-to-readme

现在新的分支已经创建，您可以开始修改文件了。你可以使用任何你想要的编辑器；Git 将通过校验和跟踪所有的变化。既然您已经做出了必要的更改，那么是时候将它们放到准备区域了。提醒一下，登台区是您放置准备拍摄的修改代码的地方。如果我们修改了“README.md”文件，我们可以使用“add”命令将其添加到临时区域。

git add README.md

您不必将修改过的每个文件都添加到暂存区，只需添加那些您希望包含在快照中的文件。既然文件已经暂存，是时候“提交”它或将它的更改放入数据库中了。我们通过使用命令“commit”并附加一些描述来实现这一点。

git commit -m "Add Mariot to the list of developers"

就这样！您所做的更改现在已保存在数据库中，并被安全地存储起来。但只能在你的电脑上！其他人看不到您的工作，因为您在自己的存储库和不同的分支上工作。为了向其他人展示您的工作，您必须将您的提交推送到远程服务器。但你必须先给高级开发人员看代码，然后再进行推送。如果他们同意，您可以将您的分支与项目的主快照合并(称为主分支)。因此，首先您必须使用“checkout”命令导航回主分支。

git checkout master

您现在在主分支上，团队的所有工作都存储在这里。但是，当您进行修复时，项目可能已经改变，这意味着团队成员可能已经改变了一些文件。您应该在将自己的更改提交给 master 之前检索这些更改。这将限制“冲突”的风险，当两个或更多的贡献者改变同一个文件时，可能发生“冲突”。要获得更改，您必须从远程服务器(也称为源服务器)中提取项目。

git pull origin master

即使另一个同事和您一样修改了同一个文件，冲突的风险也很低，因为您只修改了一行。只有当同一行被多人修改时，才会产生冲突。如果您和您的同事更改了文件的不同部分，一切正常。

现在我们已经跟上了项目的当前状态，是时候将我们的版本提交给 master 了。你可以用“合并”命令合并你的分支。

git merge add-new-dev-name-to-readme

既然提交已经合并回主服务器，那么是时候将更改推送到主服务器了。我们通过使用“推送”命令来做到这一点。

git push

图 1-10 显示了我们使用的命令和结果。

图 1-10

一个简单的 Git 工作流

就这么简单！再说一遍，如果你还没有完全理解，也不要担心。这只是 Git 通常如何使用的一个小演示。这也不太现实:没有哪个经理会像那样给新员工一张进入他们主资料库的通行证。

摘要

这只是对 Git 的一个瞥视；它有许多更强大的功能，您将在这个过程中了解到。但是在其他事情之前，在进入下一步之前，你应该问自己一些问题:“Git 将如何在我的项目中帮助我？”、“哪些功能最重要？”，以及“Git 会改善我的工作流程吗？”

本章的主要内容是分布式和集中式 VCS 之间的区别。使用 CVCS 的团队的工作流程不太有组织性，让太多的开发人员没有成就感。因此，您需要了解更多关于分布式 VCS 的知识，以跟上时代的步伐。

在本章中，我们已经看到了团队使用 Git 的典型工作流程；这是大多数团队在专业环境中甚至在开源社区中使用的工作流。即使你计划独自工作，使用工作流程也会提高你的工作效率。

现在不要担心理解 Git 的所有内容；专注于它能为你做什么。读完几章后，你就会熟悉它了。但是现在，让我们思考一下如何在您的系统上安装 Git。

二、安装和设置

现在你知道了什么是版本控制以及 Git 是如何工作的，我们将学习如何安装和设置它。这一章比其他章节要短，因为设置 Git 非常容易。

装置

安装 Git 所需的文件在所有系统的 https://git-scm.com/downloads 上。只需点击链接并选择您的操作系统。

你还可以在图 2-1 中看到，那里也有 Git 的 GUI 客户端。在完成本书的第三部分《与 Git 的团队合作》之前，不要离开。在使用 GUI 客户端之前，您需要熟悉 Git 命令；否则，您将会浪费大量时间来解决一个简单的问题，而使用简单的 Git 命令只需几秒钟。

图 2-1

截至 2019 年 5 月的 git-scm.com 下载部分

在您熟悉 Git 命令之后，您可以检查一个 GUI 客户机并亲自查看。在这本书的最后一部分有一章是关于 GUI 客户端的。但是在那之前请不要使用任何 GUI 客户端；会大大拉长你的学习时间。

注意

Git 捆绑了两个 GUI 工具:用于查看历史的 gitk 和用于基本命令的 git-gui。你将在本书的最后一部分学习使用它们，所以前面的建议仍然适用。

Windows 操作系统

在 Windows 系统上安装 Git 非常容易。打开链接( https://git-scm.com/download/win )后，下载应该会自动开始，你会到达图 2-2 所示的确认页面。如果没有，只需下载符合您的 Windows 风格的版本。

图 2-2

用于 Windows 的 Git 下载屏幕

执行下载 exe 文件开始安装。第一个屏幕是概述条款和条件的许可声明；你应该一直读到最后(对，没错)。点击下一步，您将进入类似于图 2-3 所示的组件选择屏幕。这里会提示您选择要安装的组件。我建议保留默认选项。

图 2-3

选择要安装的组件

你可以在图 2-3 中看到，你只需要检查组件来安装它们。保持选中 Windows 资源管理器集成是一个好主意；这样，您只需右键单击一个文件夹，在默认 GUI 或上下文菜单中的 Bash(命令窗口)中找到启动 Git 的选项。所有其他组件都是不言自明的，所以决定权在你。

小费

如果您没有安装 Windows 资源管理器集成，并且想要打开文件夹中的命令窗口，您必须使用 Shift +右键单击来打开扩展的上下文菜单。

做出选择后点击 next，您将看到默认的编辑器选择，如图 2-4 所示。Git 需要您定义一个默认编辑器，因为您需要一个编辑器来写出提交描述和注释。

图 2-4

默认编辑器选择

正如你在图 2-4 中看到的，由于历史原因，Vim 是 Git 的默认编辑器。只需从下拉列表中选择您最喜欢的文本编辑器。前两个，Nano 和 Vim，在控制台或命令窗口中工作，所以你不必打开另一个程序。在列表中，你可以找到许多流行的编辑器，如 Notepad++，Sublime Text，Atom 和 Visual Studio (VS) Code。如果您的编辑器没有列出，您可以选择最后一个选项，一个新的输入将会出现(如图 2-5 所示),这样您就可以提供一个到编辑器主可执行文件的链接。

图 2-5

设置自定义编辑器

在图 2-5 中，您可以看到这样一个屏幕，如果它没有在下拉列表中列出，您可以在这里设置您的自定义编辑器。

对于这本书，我决定保留默认选项，使用 Vim。如果你决定使用其他编辑器，这不会改变这本书的任何内容。但是如果你想学习 Vim(需要一点时间)，你可以看看“vimtutor”，这是 Vim 附带的一个辅导程序，或者通过 https://vim-adventures.com/ 上一个有趣的视频游戏来学习。还有 www.vi-improved.org/vimusermanual.pdf 更全但是 300 多页！

不要担心，这个选择不是决定性的，你仍然可以随时改变。你将在本章的最后一节了解如何操作。

警告

在网上，永远不要开始或参与编辑大战。选择你喜欢的文本编辑器，不要和任何人谈论它。我仍然带着过去在“Emacs vs. Vim”战争中留下的伤疤。

一旦你选择了你喜欢的编辑器，你就可以进入下一个屏幕，这是路径环境调整，如图 2-6 所示。PATH 环境是一个变量，它包含可执行程序在其值中所在的目录列表。这是必需的，这样当你想在控制台中执行一个可执行文件时，你就不必键入它的完整路径；你只需要输入它的名字。例如，要从控制台启动 Visual Studio 代码，我应该键入 C:\ Program Files(x86)\ Microsoft VS Code \ bin \ Code。但是由于我的路径中有 C:\ Program Files(x86)\ Microsoft VS Code \ bin，所以我只需键入“Code”即可启动它。

图 2-6

选择是否将 Git 添加到路径

如果你愿意，这同样适用于 Git。如果您不希望这样，而只想将 Git 与它自己的独立控制台“Git Bash”一起使用，请选择第一个选项。因此，要使用 Git，您必须从应用列表或文件夹的上下文菜单中启动它(如果您选择安装 Windows 资源管理器集成)。

如果您希望能够在任何地方使用 Git，请保留默认选项，将其添加到您的 PATH 环境中。这样，其他工具也可以使用 Git，您可以从任何命令窗口工作。我强烈建议这个选项。

最后一个选项有点侵入性。它将向您的路径添加许多 Git 命令，并将覆盖一些 Windows 的默认工具。只有在您也有正当理由的情况下才选择此项；一般你没有这样的理由。

如图 2-6 所示选择一个选项，进行下一步。您将到达一个关于 HTTPS 连接的屏幕，如图 2-7 所示。通过 HTTPS 发送数据时，您必须选择使用哪个库。在本书的后面，您将不得不连接到一个远程服务器(因为 Git 是一个分布式 VCS)来与其他人共享您的提交，因此所有这些连接都必须加密，以进一步保护您的数据，确保它们不被窃取。

图 2-7

选择 HTTPS 交通工具

除非有理由(公司政策或您自己的小安全设置)，否则请使用默认选项。

在这之后，进入下一步，这是关于行尾。这又是一个选择屏幕，所以你的屏幕应该如图 2-8 所示。不同的操作系统对文本文件的操作是不同的，尤其是在处理行尾的时候。您将要合作的团队可能会使用不同的操作系统。因此，在共享提交之前，Git 需要将行尾和每种结尾风格相互转换。

图 2-8

行尾转换

因为您将使用 Windows，所以应该选中默认选项。如果您不注意行尾，其他两个选项会对您的提交造成很大的损害。选择默认选项后，您可以进入下一步。

警告

这一步很重要，因为 Windows 和 MacOS 使用\r\n 而不是 Linux 的\n 来结束行，如果您不转换，您的文件将变得非常难以阅读，Git 将检测到许多更改，即使没有进行那么多更改。

下一步是选择默认的终端(或控制台)模拟器。这是一个简单的选择屏幕，如图 2-9 所示。Git Bash 需要一个控制台模拟器才能工作，所以您需要选择一个。默认模拟器是 MinTTY，另一个选项是 Windows 的默认控制台。

图 2-9

选择终端模拟器

我建议保留默认选项，因为 MinTTY 可以做 Windows 控制台窗口可以做的一切，但在各方面都更好。单击“下一步”进入最后一步。

我们现在处于最后阶段！这个安装就要结束了。只是在额外选项屏幕上做了一些调整。这个屏幕(如图 2-10 所示)允许您启用一些额外的特性，这些特性将会很好地配合您的 Git 安装。例如，Git 凭证管理器将帮助您安全地连接到远程服务器，并与其他 Git 工具配合良好。

图 2-10

配置额外选项

只要保留默认选项，除非你有理由不这样做。之后，只需启动安装并让它完成。就这样！Git 安装在您的 Windows 系统上。但是在使用它之前，请跳到下一节来正确设置它！

苹果个人计算机

如果你已经用 Mac OS X 做过一些软件开发，你可能已经有 Git 了，因为它是和 XCode ( https://developer.apple.com/xcode/ )一起安装的。您可以通过从控制台运行以下命令来检查您是否拥有 Git:

$ git --version

它应该给你当前安装的 Git 版本，或者如果没有安装，提示你安装 XCode 的命令行工具。如果在提示符下选择 install，将会安装 Git，您可以跳过本节的其余部分。

要在 Mac 上安装 Git，只需进入下载链接 https://git-scm.com/download/mac ，下载应该会自动开始，如图 2-11 所示。执行下载的文件，安装将开始；这很简单。

图 2-11

用于 Mac 的下载屏幕

也可以用家酿( https://brew.sh/ )安装。只需运行命令:

$ brew install git

这将安装大约一半的宇宙，但它最终会停止，Git 将被安装。

就是这样！对于 Mac OS X 来说，安装 Git 要简单得多，你可能已经有了。

Linux 操作系统

如果你经常使用 Linux，你可能比我更了解你的发行版。因此，用您的包管理器安装 Git 对您来说可能是小菜一碟。

对于 Ubuntu 和 Debian 风格的发行版，您使用 APT 来安装 Git。

$ sudo apt-get install git

或者

$ sudo apt install git (for newer systems)

对于 Fedora，您可以使用 YUM 或 DNF。

$ sudo yum install git

或者

$ sudo dnf install git (for newer systems)

如果你有一个不同的发行版，你可以检查 https://git-scm.com/download/linux 来获得一个关于如何为每个流行的发行版安装 Git 的命令列表。这个列表应该类似于图 2-12 所示的列表，越来越多的 Linux 版本将会出现。

图 2-12

如何在 Linux 上安装 Git

使用图 2-12 中列出的与您的发行版相对应的命令后，Git 就安装好了！

警告

就像编辑战一样，发行战在网上是一大禁忌。

设置 Git

在开始使用 Git 之前，您需要先做一些设置。您可能只需要这样做一次，因为所有的设置都存储在一个外部全局文件中，这意味着所有的项目都将共享相同的配置。还有一种方法可以逐个配置项目，但我们将在后面看到这一点。

由于 Git 是一个分布式版本控制系统，总有一天你会需要连接到其他远程存储库。为了避免犯任何身份错误，有必要告诉 Git 一些关于你自己的情况。不用担心；它不会问你一个有趣的事实！

要设置 Git，请打开 Git Bash(对于 Windows 系统)或默认控制台窗口(对于修改了路径环境的 Linux/MacOS 或 Windows 系统)。在命令提示符下，只需告诉 Git 您的姓名和电子邮件地址:

$ git config --global user.name "Mariot Tsitoara"
$ git config --global user.email "mariot.tsitoara@gmail.com"

请注意“全局”参数；这意味着该设置适用于所有将来的 Git 存储库，因此您不必在将来再次设置它。

使用 config 命令，您还可以更改您的默认编辑器。如果您因为找到了新的编辑器或者卸载了自己的编辑器而想要更改编辑器，config 命令可以帮助您。例如，要将默认编辑器更改为 Nano，您可以键入

$ git config --global core.editor="nano"

您可以在您的主文件夹中找到记录 Git 配置的文件。对于 Windows，可以在 C:\Users\YourName.gitconfig 中找到，对于 Linux 和 Mac OS，可以在/home/yourname/中找到。gitconfig 如图 2-13 所示。

图 2-13

我的 .gitconfig 文件

紧挨着。gitconfig 文件，您可能会找到另一个名为。bash_history 记录您在控制台上输入的所有命令。如果你想重新检查你忘记的命令，你可以检查这个文档。

摘要

让我们复习一下到目前为止所学的内容！首先，现在您应该已经在系统上安装了 Git。安装过程在 Windows 上非常容易，在 Mac 和 Linux 上更容易。如果你不确定你需要什么，我建议你保留所有的默认选项(即使在前面的截图中没有显示)。

接下来是设置。在安装 Git 的每个系统中，您只需要这样做一次。Git 将使用你的名字和电子邮件来签署你的每一个动作，所以在你使用它之前有必要设置它们。

就这样！您现在已经准备好使用 Git 的所有优点了。阅读下一章，从 Git 开始。

三、入门指南

您终于准备好开始使用 Git 了！在这一章中，你将学习一些任何项目都需要的 Git 术语和概念。然后，您的任务是建立一个项目，对其进行更改，检查更改，最后在不同版本之间导航。走吧！

仓库

存储库是保存所有项目和对项目所做的所有更改的存储器。你可以把它想象成一个“变化数据库”但是不用担心；它只是你系统中的一个普通文件夹，所以很容易操作。

对于您想用 Git 管理的每个项目，您必须为它建立一个存储库。建立一个存储库非常容易。只需导航到您想要跟踪的文件夹，并告诉 Git 在那里启动一个存储库。

所以对于每个你想开始的项目，你应该

• 创建包含您的项目的目录

• 导航到目录

• 初始化 Git 存储库

看到了吗？很简单。让我们将这些语句转换成命令。但是首先，让我们打开一个控制台来输入我们的命令。对于 Linux 用户来说，你只需要启动你喜欢的终端(对于 Debian 之类的发行版，Ctrl-Alt-T)。对于 MacOS，你只需要使用 Cmd-Space 来调出 Spotlight，在那里你可以搜索终端应用。Windows 用户可以打开两个控制台:cmd 和 powershell。Powershell 更现代，有类似 UNIX 的命令。要打开其中一个，请使用 Windows-R 并键入名称(cmd 或 powershell)。注意，如果您打开了这些控制台，那么在第一次安装 Git 时，您需要重新启动所有这些控制台。Git for Windows 还附带了一个名为 Git Bash 的控制台模拟器，它提供了一个类似于 Linux 和 Mac 控制台的环境。如果你使用 Windows，我强烈建议使用 Git Bash，这样你就可以和其他使用不同操作系统的人有相同的体验。

打开 Git Bash(从应用列表或上下文菜单中)，并键入以下命令:

$ mkdir mynewproject

$ cd mynewproject/

$ git init

mkdir 是用于创建目录的命令；它是“制作目录”的缩写 cd 是用于在目录间导航的命令；它是“更改目录”的缩写最后， git init 是“Git initialize”的缩写

初始化存储库后，Git 会告诉你数据库是在哪里创建的，如图 3-1 所示。

图 3-1

新储存库的初始化

注意

mkdir 和 cd 是系统命令；它们由操作系统管理，而 init 是一个 Git 命令。每个 git 命令都以“Git”开头。

Git 将创建一个名为。git ”,它将包含您所有的变更集和快照。如果你想签出它，你必须从你的文件资源管理器的设置中显示隐藏文件。存储库看起来如图 3-2 所示的目录。

图 3-2

一个空仓库

如果你打开。git 目录中，您会发现更多属于 Git 数据库的项目。查看图 3-3 中的示例。

图 3-3

在里面。git 目录

还记得第一章说 Git 不是跟踪版本之间的变化，而是拍摄快照吗？嗯，所有这些快照都存储在”。git”目录。每个快照被称为“提交”，我们将在本节结束后不久对此进行研究。

头文件在此”。git”目录指向您正在工作的项目的当前“分支”或子版本。默认的分支被称为“主”，但是它就像任何其他分支一样；这个名字只是一个老约定。

您还应该知道初始化是获得存储库的唯一方法。您可以复制整个存储库及其所有历史和快照。它被称为“克隆”，我们将在另一章中看到。

练习:创建一个空存储库

我们的第一次演习并不完全是火箭手术。只需在系统中的某个地方创建一个空的存储库。您可以使用默认控制台或 Git Bash。

工作目录

“外面的空地呢。git”目录？它被称为工作目录，您将要处理的文件将存储在那里。通常，您的最新版本会在工作目录中。

您处理的每个文件都在工作目录中。这个地方没有什么特别的地方，除了你只能直接操作这里的文件。永远不要修改里面的文件。git”目录！

Git 将检测你放入工作目录的任何新文件。您可以使用 Git 命令“status”来检查目录的状态

$ git status

例如，如果我们在工作目录中创建了一个名为 README.md 的新文件，我们会看到 Git 会知道项目已经更改。确保将新文件放在。git 目录如图 3-4 所示，不要放入其中！

图 3-4

在工作目录中创建新文件

如果我们检查工作目录的状态，我们将得到如图 3-5 所示的结果。

如图 3-5 所示，我们还没有任何提交；这是因为我们仍在工作目录中，还没有拍摄任何快照。它还说我们在“主”分支上；这是在存储库初始化时创建的唯一分支的默认名称。然后我们得到未被追踪的文件。这些是我们修改过的文件(在本例中是创建的)。

图 3-5

工作目录的状态

本质上，这就是工作目录:您直接与项目文件交互的地方。

练习:为项目创建一些文件

这个练习也很简单。只需在项目目录(存储库)中创建一些文件，并检查工作目录状态。

部队从一个战场转往另一个战场的集结地

暂存区是拍摄快照前文件存放的地方。在拍摄项目当前状态的快照时，并不是您在工作目录中修改的每个文件都应该被考虑在内。只有放置在临时区域中的文件才会被拍摄快照。

因此，在拍摄项目快照之前，您需要选择要考虑哪些已更改的文件。文件中的更改可以是创建、删除或编辑。

把它想象成指定哪些文件要出现在全家福照片中。为了将文件添加到临时区域，我们使用 Git 命令“add”

$ git add nameofthefile

就这么简单。如果我们想要存放我们之前创建的 README.md，我们将使用“git add README.md”。或者，如果您创建了多个文件，您可以像“git add file1 file2 file3”那样依次或一起添加它们

让我们使用以下命令来存放我们的新文件:

$ git add README.md

然后让我们用 git status 命令检查状态。

$ git status

将文件添加到暂存区不会产生任何可见的结果，但是检查状态会得到类似于图 3-6 的结果。

图 3-6

暂存文件

如果您查看图 3-6 ，您会注意到在暂存文件之后，工作目录又变得干净了。这是因为“git status”只跟踪“未暂存”的文件(未标记为快照的已编辑文件)。

正如你在图 3-6 中看到的，你也可以使用 Git 命令“git rm”和选项“- cached”来卸载一个文件

$ git rm --cached README.md

警告

在卸载文件时，不要忘记选项“- cached”。如果你忘记了，你可能会丢失你的文件！

在转移了所有希望更改生效的文件后，现在就可以拍摄第一个快照了！

练习:暂存和取消暂存文件

获取您在上一个练习中创建的文件并转移它们。取消转移一个文件并重新转移它。在每个阶段/取消阶段后检查工作目录状态。

承诺

就像我们在这一部分之前讨论过的，提交只是整个项目在某一时刻的快照。Git 不记录对文件所做的单独更改；它拍下了整个项目的照片。

除了快照之外，提交还包含有关内容的“作者”和“提交者”的信息，或者是谁将变更集放入了存储库。

注意

“作者”和“提交者”通常是同一个人，除非提交者从另一个团队成员那里获得变更集。请记住，Git 提交是可交换的，因为它是分布式 VCS。

因为提交是项目状态的快照，所以项目的前一个状态是另一个被称为“父”的提交第一次提交是在创建存储库时由 Git 创建的，并且是没有父提交的提交。所有将来的提交都通过父子关系相互链接。这些互为父级的提交的集合称为“分支”

注意

如果一个提交有两个父级，这意味着它是通过合并两个分支创建的。

提交由其名称标识，名称是通过散列提交获得的 40 个字符的字符串。这是一个简单的 SHA1 散列，因此具有相同信息的多个提交将具有相同的名称。

对特定提交的引用称为“head”，它也有一个名称。而你目前正在做的头部叫做“头”(见上一节)。

我们现在可以提交之前暂存的文件。在每次提交之前，您应该检查工作目录和临时区域的状态。如果您想要提交的所有文件都在临时区域中(在短语“要提交的更改”下)，您可以提交。否则，您必须使用“git add”来存放它们

为了提交我们所做的所有更改，我们使用“git commit”这将对项目的当前状态进行快照。

$ git commit

如果我们执行这个命令，它将打开我们的默认编辑器(如果您想修改您的编辑器，请查看第二章),并要求我们提交消息。提交消息是对与前一次提交相比，提交中发生了什么变化的简短描述。

我的默认编辑器是 Vim，所以如果我执行 commit 命令，我会看到如图 3-7 所示的屏幕。

图 3-7

Git 打开默认编辑器，这样您就可以编辑提交消息

在图 3-7 中可以看到文件的第一行是空的；这是您必须编写提交消息的地方。提交消息应该写在一行上，但是您可以添加多行注释。注释以“#”开头，被 Git 忽略；它们仅用于完成提交消息，使其更加清晰。还要注意，Git 会自动将已更改文件的列表放入提交注释中(与您在“git status”中看到的文件相同)。

在后面的章节中，你会学到正确编写提交消息的正确方法。但是现在，只需在第一个空行输入一条简单的消息，如图 3-8 所示,“将 README.md 添加到项目中”。

图 3-8

写在文件顶部的提交消息

如图 3-8 所示编写提交消息后，您可以关闭编辑器(保存后！).然后你会得到一个提交的概要，如图 3-9 所示。

图 3-9

提交摘要

提交摘要将包含大量信息:

• 当前分支:主

• 前一次提交的名称:root-commit，因为这是我们的第一次提交

• 提交的名称:提交散列的前七个字母

• 提交消息

• 更改的文件数量:一个文件

• 对每个文件所做的操作:创建

我们拍了第一张快照！如果您检查存储库的状态，您可以看到它又是干净的，除非您留下了一些未转移的文件。

练习:提交您的更改

从上一个练习中取出您的暂存文件并提交它们。然后修改一个被跟踪的文件，再次登台，并进行新的提交。比较每次提交的摘要。有什么不同？这些提交是如何联系在一起的？

Git 快速入门

现在，您已经熟悉了 Git 的基本概念，我们将在一个真实的项目中应用它们。让我们假设您想要创建一个文件夹来保存您的待办事项列表，并希望对其进行版本控制，以便您可以检查每个项目何时完成。

为了让您更熟悉 Git，您将在没有任何帮助的情况下进行下一个练习。如果你卡住了，只需查看前面的部分的方向。

只要记住 Git 的基本原则:

• 您可以修改工作目录中的文件。

• 您将想要记录当前状态的文件放在暂存区。

• 您通过提交来获取项目的快照。

不要忘记在提交之前将您修改的文件放在暂存区，否则它们将不会成为快照的一部分。您没有放在暂存区的修改过的文件将只保留在工作目录中，直到您决定放弃它们或者在将来的提交中包含它们。

让我们开始练习吧！请完成它直到结束，不要进入下一章，直到你明白 Git 是如何工作的。

练习:版本化的 TODO 应用

• 创建新的存储库。

• 在目录中创建一个名为 TODO.txt 的文件，并输入一些文本。

• Stage TODO.txt

• 提交项目并放入一条简短的提交消息。

• 创建两个名为 DONE.txt 和 WORKING.txt 的新文件。

• 暂存并提交这些文件。

• 将 WORKING.txt 重命名为 IN PROGRESS.txt。

• 向 DONE.txt 添加一些文本。

• 检查目录状态。

• 阶段进行中. txt 和完成. txt。

• Unstage DONE.txt。

• 提交项目。

• 检查目录状态。

完成这个练习后，合上书，试着用自己的话解释这些事情:

• 工作目录

• 部队从一个战场转往另一个战场的集结地

• 犯罪

如果您在理解这些概念方面没有太多问题，那么您已经准备好学习更多的 Git 命令和概念了。

摘要

这一章对你理解 Git 非常重要。主要要点是文件的三种状态:

• 修改:您修改了工作目录中的一个文件。

• 暂存:您将文件添加到暂存区域，以便可以对其进行快照。

• 已提交:您拍摄了整个项目的快照(所有未修改的和暂存的文件)。

如果文件是上一次提交的一部分，而您没有修改它们，它们将自动成为下一次提交的一部分。已修改但未转移的文件被视为未修改。您必须要求 Git 通过暂存这些文件来跟踪它们。

我们还学习了一些关于提交和提交消息的知识。一开始，打开外部编辑器来编写提交消息可能会有点笨拙，但是过一段时间后，您最终会掌握它的窍门。

在下一章，我们将学习如何检查项目历史和在版本之间导航。我们还将了解如何忽略某些文件，并显示自上次提交以来对项目所做的当前更改。

四、深入 Git

现在您已经熟悉了 Git 的基本命令，我们将深入研究它的其他特性。你将在本章中发现我在第一章中承诺给你的特性。

忽略文件

Git 不应该跟踪工作目录中的所有内容。有些文件(配置、密码、错误代码)通常不会被作者或开发人员跟踪。

那些文件(或目录)被列在一个名为“. gitignore”的简单文件中，注意“gitignore”之前的句点；这很重要。要忽略文件，请创建一个名为。gitignore 并在其中列出要忽略的文件或文件夹。

让我们回到上一章的知识库，待办事项列表。假设您想要包含一个名为 PRIVATE.txt 的私有的、未被跟踪的文件。使用您最喜欢的文本编辑器忽略文件，然后在其中写入 PRIVATE.txt，如图 4-1 所示。

图 4-1

的。git 忽略包含 PRIVATE.txt 的文件

如果您随后创建并修改 PRIVATE.txt 文件(如图 4-2 所示)，如果您检查状态，Git 不会考虑它。

图 4-2

添加 PRIVATE.txt

让我们试着检查一下状态。

$ git status

你会得到如图 4-3 所示的类似结果。

图 4-3

工作目录的状态

在图 4-3 所示的状态上可以看到，PRIVATE.txt 没有被跟踪。您还可以看到。gitignore 文件被跟踪；因此，您必须在修改后添加并提交它。

$ git add .gitignore
$ git commit

像往常一样，暂存一个文件，然后提交项目，将会产生一条确认消息，总结所做的更改(如图 4-4 所示)。

图 4-4

承诺。被增加

请记住。gitignore 全局文件应该放在你的库的根目录下。如果将它放在一个目录中，只有该目录中的匹配文件会被忽略。一般来说，有多个。gitignore 多个目录中的文件被认为是一个糟糕的举动，除非你的项目非常庞大。更喜欢把它们列成一个。gitignore 文件放在你的库的根目录下。

您可能会问自己在使用 Git 时应该忽略哪种文件。经验法则是忽略项目生成的所有文件。例如，如果您的项目是一个软件源代码，您应该忽略编译后的输出(可执行文件或翻译文件)。临时文件和日志，以及大型库(node_modules)也应该被排除在外。不要忘记排除所有的个人配置和文本编辑器的临时文件。

的。gitignore file 不仅忽略按名称列出的文件；您也可以忽略与描述匹配的目录和文件。您将在表 4-1 中找到您可以使用的所有模板的便捷提示。

表 4-1

。git 忽略行和它们的作用

|

。吉塞尔线

|

什么被忽略了

|

例子

| | --- | --- | --- | | 配置文件 | 任何目录中的 config.txt | 配置文件本地/配置. txt | | 构建/ | 任何构建目录和其中的所有文件。但不是名为 build 的文件 | 构建/目标. bin 构建/输出. exe 不输出/构建 | | 建设 | 任何构建目录、其中的所有文件以及任何名为 build 的文件 | 构建/目标. bin 输出/构建 | | * exe | 所有带有扩展名的文件。可执行程序的扩展名 | target.exe 输出/res.exe | | bin/* . exe | 所有带有扩展名的文件。bin/目录中的 exe 文件 | bin/output.exe | | 临时议程* | 名称以 temp 开头的所有文件 | 临时雇员温度箱临时输出 | | □配置 | 任何名为 configs 的目录 | config/prod . py 本地/config/prep rod . py | | □config/local . py | 任何名为 configs 的目录中任何名为 local.py 的文件 | config/local . pyserver/configs/local.py 不是 configs/fr/local.py | | output/∫∫/result . exe | 输出中任何目录下的任何名为 result.exe 的文件 | 输出/结果输出/最新/结果. exe 输出/1991/12/16/result.exe |

这些是与. gitignore 一起使用的最常见的行。还有其他的行，但它们只在非常特殊的情况下使用，在普通项目中几乎从不使用。如果你使用的是计算机语言或框架，你可以去 https://github.com/github/gitignore 获取模板。git 忽略您应该使用的文件。

但是如果您想忽略除了一个文件之外的所有匹配描述的文件呢？嗯，您可以告诉 Git 忽略所有文件，然后立即进行例外处理。要从忽略列表中排除某个文件，请使用“！."例如，如果您想忽略除 output.exe 之外的所有 exe 文件，您将编写您的。gitignore 如图 4-5 所示。

图 4-5

如何破例

注意各行的顺序。规则之后是例外！

不过，这个异常标记只对描述文件名的行有效。你不能用它来忽略目录。如图 4-6 所示的. gitignore 文件不起作用。

图 4-6

异常不适用于目录匹配忽略的文件

练习:忽略文件和目录

从上一个练习中取出您的存储库，并创建多个文件和目录。检查表 4-1 并尝试忽略您使用每一行创建的文件。根据需要创建尽可能多的文件，在理解每个模式之前不要停止。不需要记住所有的东西，但是你至少应该知道什么时候应该使用它们。

练习:这些行忽略了什么

检查图 4-7 。不看上一节，每行忽略了什么？

图 4-7

猜猜每行忽略了什么

你就是这样忽略文件的！这几乎和忽视你的责任一样简单！但是请记住。gitignore 文件被跟踪和版本化，所以不要忘记在提交之前暂存它！

检查日志和历史记录

如果您遵循了练习(正如您应该做的),或者开始在您自己的项目中使用 Git，那么您现在会遇到一个小问题，我曾保证使用 Git 可以很容易地解决这个问题:如何查阅历史日志。

这是 Git 最常用的特性之一，也是最简单的 Git 命令之一:git log

$ git log

试试看！打开您的存储库并运行命令。您应该会看到如图 4-8 所示的视图。

图 4-8

提交日志

提交日志将列出您或其他人提交的所有快照(从最新的到最早的)。对于每次提交，它还包括

• 名称(唯一的，通过哈希获得)

• 作者

• 日期

• 描述

由于提交名称太长，我们将只使用前五个字母作为名称。这对下一节很重要。

如果您的提交历史非常长，您可以使用键盘开始

• 向前或向后一行:上下键或 j 和 k 键

• 向前或向后一个窗口:f 和 b

• 在日志的末尾:G

• 在日志的开头:g

• 获取帮助:h

• 退出日志:问

git log 有许多参数可以使用；表 4-2 正在向您展示。

表 4-2

最常见的 git 日志参数

|

命令

|

使用

|

例子

| | --- | --- | --- | | git log --reverse | 颠倒提交的顺序 |   | | git log -n <number> | 限制显示的提交数量 | git log -n 10 | | git log --since=<date>``git log –after=<date> | 仅显示特定日期后的提交 | git log --since=2018/11/11 | | git log --until=<date>``git log --before=<date> | 仅显示特定日期之前的提交 |   | | git log --author=<name> | 显示来自特定作者的所有提交 | git log --author=Mariot | | git log --stat | 显示变更统计 |   | | git log --graph | 在简单的图形中显示提交 |   |

练习:显示历史记录

这个练习很简单。只需重新打开上次练习中的存储库，并检查历史日志:

• 以相反的顺序

• 从昨天开始

• 对于最后两次提交

查看以前的版本

既然您已经知道了如何检查历史和提交日志，那么是时候检查文件了，首先看看哪些文件发生了更改。

还记得每次提交时创建的那些长名字吗？我们将使用它们在提交或快照之间导航。要检查特定快照上的文件，只需知道它的名称。知道每个提交名称的最好方法是查看历史日志，如图 4-9 所示。

图 4-9

待办事项列表的历史记录

要显示和了解对项目做了哪些更改，只需使用“git show”命令，后跟提交的名称。你甚至不需要写全名，只需要前七个字母。

$ git show <name>

尝试使用您的存储库！您应该会得到如图 4-10 所示的结果。

图 4-10

git 显示的结果

如您所见，提交以非常详细的方式显示。您将看到所选提交和前一个提交之间的差异。增加的用绿色显示，删除的用红色显示。您可以使用“git show”命令显示任何提交的细节。

练习:检查您对项目所做的更改

列出您对项目所做的提交，并检查每个提交的更改。

查看当前的更改

检查以前的版本是很好的，但是如果您只想检查您刚才所做的更改呢？检查最后一次提交和当前工作目录之间的差异是 Git 的一个基本特性。你会经常用到它！检查差异的命令很简单:git diff。

$ git diff

修改目录中的一个或多个文件，然后执行命令。您将得到如图 4-11 所示的结果，这与上一节中 git show 命令的结果非常相似。它们实际上是相同的视图，因为显示的信息是相同的。

图 4-11

检查工作目录中的所有更改

大多数情况下，您只需要检查对单个文件的更改，而不是对整个项目的更改。您可以将文件名作为参数传递，以查看它与上次提交时的差异。

$ git diff TODO.txt

要记住的主要事情是 git diff 检查对工作目录中的文件所做的更改；它不检查暂存文件！要检查对暂存文件所做的更改，您必须使用参数“- staged”

$ git diff --staged

在提交项目之前，您应该总是检查暂存文件中的差异，这样您就可以做最后的检查。我知道有一天你会忘记这么做，所以去下一章学习如何撤销或修改你的提交。

本章到此结束，我们学到了很多东西。在进入下一章之前，请确保您熟悉这些功能:

• 忽略文件

• 检查历史日志

• 审查本地和阶段性变更

如果你是，并且你完成了练习，祝贺你！但是我们还没有完成提交！

摘要

这一章是关于项目历史的。我们学习了使用 git log 和 git show 检查日志，还学习了使用 git diff 检查当前的更改。Git log 和 git diff 在未来会特别有用，所以一定要好好理解它们。Git diff 是将当前修改的文件与上次提交的文件进行比较，而 git log 只是所有以前提交的列表。

忽略文件的能力。gitignore 也是一项很好的技能，这样您的 git 状态就不会被您不想提交的修改过的文件饱和。这也是确保特定文件(可能包含密钥)不会被意外提交的好方法。

在下一章，我们还有很多关于提交的内容要学。我们将首先回顾 Git 文件的三种状态，然后我们将看到如何将以前的版本带回工作目录。您至少将学习如何撤销和修改提交。抓紧了！

五、提交

前一章教了你一些关于 Git 的基本特性。您应该知道如何检查历史日志并查看对当前版本所做的更改。但是 Git 提交是一块难啃的骨头，所以我们将在本章中更多地讨论它们。首先，我们将(再次)探索 Git 的内部工作及其术语。然后，我们将学习如何查看和检查以前的版本。我们走吧！

Git 的三种状态

在详细讨论提交之前，我们必须回到基础，重新了解 Git 是如何工作的。您肯定记得文件可以找到自己的三种状态。如果没有，就不要跳过这一章；这对于您使用 Git 所做的一切都是必不可少的。如果你记得，也不要跳过，因为我花了很多时间写的。

正如你在上一章看到的，Git 并不是跟踪所有的文件；一些文件被忽略(由。gitignore 文件)。还有一些文件没有被忽略，但是还没有被 Git 跟踪。它们是新创建的文件，从未包含在快照中(提交)。

被跟踪的文件可以有三种状态:

• 修改:您更改了文件。

• 已转移:您更改了文件并准备拍摄快照。

• 已提交:您拍摄了整个项目的快照，文件就在其中。

未跟踪的文件将保持原样，直到您决定暂存并提交它们或明确忽略它们。

记住:Git 不跟踪变化，它跟踪快照。每次提交时，整个项目的状态都会被保存，而不仅仅是所做的微小更改。

书呆子的事实:Git 很快，因为你总是在项目的最后状态工作。当您想要查看以前的提交时，它只是向您显示项目在那个特定时间的状态。许多 VCS 存储对一个文件所做的每一个更改，当您想回到以前的状态时，它们会反向重放这些更改。当项目变大时，这会导致许多问题，如速度和内存。Git 的思维方式不就是创建超级大数据库吗？不会，因为当你拍快照的时候，一个文件没有变化，它不会再被存储；而是使用对文件的引用。

让我们再回到这三个状态，看看它们之间的关系:

• 你在工作目录上工作。它只是您在初始化存储库之前创建的目录。这是你阅读和编辑文件的地方。

• 临时区域是您在拍摄整个项目的快照之前放置已更改文件的地方。如果不暂存已更改的文件，则不能拍摄快照。快照中将只考虑转移的文件(和未更改的文件)。未转移的文件(跟踪或未跟踪)和忽略的文件将保持相同的状态。

• 数据库或者。git 目录存储您拍摄的每个快照。这些快照称为提交。

记住:暂存只关注你选择的变更文件，而提交关注整个项目。你暂存一个文件；然后提交项目。

在版本间导航

很多时候，您不仅想知道项目中发生了什么变化，还想知道它处于什么状态，想看看您拍摄的快照。用 Git 很简单。

当您想要将项目的先前状态带到工作目录中时，我们必须使用“git checkout”来检查提交因为这会更改工作目录中的文件，所以您必须确保那里没有任何未转移的文件。未跟踪的文件很好，因为 Git 还没有跟踪它们的状态。

为了检查项目的快照，我们使用“git checkout”命令并将提交名称作为参数传递。

$ git checkout <name>

我们试试吧！在文本编辑器中打开当前项目，记下其内容。现在检查之前的提交，如图 5-1 所示。

图 5-1

签出旧的提交

警告

如果您的工作目录不干净，您就不能检查任何其他提交！请确保在切换快照之前提交您的更改。

检查以前的提交时，注意不要更改任何内容。就像电影里一样，改变过去是一个非常糟糕的主意！

如果您检查您的文本编辑器，您会注意到项目现在就像您拍摄快照时一样。这就是 Git 的最佳之处。您拍摄的快照不会丢失任何东西！

现在让我们学习一些 Git 术语。首先是“头”“头”只是对提交的引用。当谈到提交时，我们不说“名字”，而是说“头”

当在不同的提交之间切换时，我们需要一种方法来知道我们在哪个“头”上。当前头(被检出的那个)只是被称为“头”

就这样！head 是对提交的引用(一个存储库中可以有多个 head)，指向当前签出的提交的 HEAD 称为 HEAD。

练习:在你的历史中移动

使用“git checkout”从一个提交转移到另一个提交确保不要更改任何内容。

但是如何返回到正常的当前工作目录呢？因为我们没有对我们的存储库做任何大的改变，所以返回到工作目录只是检查我们拥有的唯一的分支。按照惯例，那个分支叫做“主”

$ git checkout master

试试看！记住时间旅行的两条黄金法则:

• 只有当现在是干净的时候(工作目录中没有未存储的内容)，才可以回到过去。

• 不要改变过去(直到你有了更多的经验)。

在版本之间导航后，不要忘记检查当前的分支(主)。

撤消提交

总有一天，你会暂存并提交文件，但随后又改变主意。每个人都会这样。但是使用传统的方法(没有版本控制)，回滚更改是非常困难的，特别是如果更改发生在很久以前。对于 Git，它只是一个命令:git revert。

为什么不直接删除提交？因为上一节的时间旅行规则:永远不要改变过去。为了历史，无论发生什么变化，都必须保持不变；改变过去发生的事情是非常危险和违反直觉的。相反，您将使用 git revert 创建一个新的提交，它包含与您试图撤消的提交完全相反的提交。

所以，撤销提交只是提交了它的反面。就这么简单！要使用它，您必须将要撤销的提交的名称作为参数传递。

$ git revert <commit name>

您可以恢复任何提交；只要确保在一个干净的工作目录下工作。因此，在恢复提交之前，不要忘记暂存和提交您的文件。我们试试吧！

首先，确保工作目录是干净的，如图 5-2 所示。

图 5-2

使用 git status 检查工作目录

太好了。既然我们知道工作目录是干净的，那么是时候检查历史以了解要撤销哪个提交了。我们应该会得到如图 5-3 所示的结果。

图 5-3

使用 git 日志检查提交历史记录

注意

如果您不喜欢提交历史的显示方式，可以传递“- oneline”参数来减少显示的信息。查看图 5-4 中的示例。

图 5-4

更漂亮的 git 日志输出

让我们恢复第三次提交！我们只是使用 git revert 后跟提交名。

$ git revert 5f57824

因为 git revert 只创建一个包含相反更改的新提交，所以过程的其余部分与任何新提交相同。如图 5-5 所示，您将被要求描述您的新提交。我建议总是保持默认的提交描述，因为它很容易识别。

图 5-5

新提交描述

保存提交描述后(像所有提交一样)，您将看到快照内容的摘要。图 5-6 显示了运行命令并保存提交描述后的结果。

图 5-6

回复的摘要

如您所见，使用 Git 撤销更改非常容易。需要记住的是 git revert 只会创建一个包含相反更改的新提交。这意味着您可以恢复一个恢复！恢复一个还原只会重新应用您的原始提交，并且两个“还原”会相互取消。但是，这些提交将保留在您的历史日志中，因为您无法改变过去。

注意

其实你可以改变过去。但是永远不要这样做。这是一个非常糟糕的主意，它只会给你带来更多的问题。

修改提交

正如我在上一章中所承诺的，你将在本章中学习如何修改提交。当您忘记存放文件或想要更改提交消息时，可以使用此选项。这不应该用来修改很多文件，因为这是违反直觉的。下一章将详细讨论何时何地使用这个。我再说一遍:永远不要试图改变过去。

要修改提交，您必须使用 git commit 命令，但是要使用“- amend”作为参数。它将像普通提交一样打开您的默认文本编辑器，但是已经有了暂存文件和提交消息。

$ git commit --amend

然后，像每次提交一样，保存并关闭文本编辑器。我使用的“修改”这个词有点误导，因为你不是在修改一个提交；您正在创建新的提交并替换当前的提交。所以，从现在开始，我会用“修正”这个词

修改提交会获取暂存区域中的所有内容，并使用它进行新的提交。因此，如果您想在提交中添加一个新文件或从中删除一个文件，您可以随意存放和取消存放它们。提醒:要卸载一个文件，你必须使用 git reset HEAD 。这里有一个小例子。

让我们再次使用我们的 TODO 应用。编辑现有文件；然后创建两个名为 filenottocommit.txt 和 fileforgotten.txt 的新文件，如图 5-7 所示。

图 5-7

我们工作目录中的所有文件

您可以通过执行 git status 命令来检查项目的当前状态:

$ git status

根据您之前添加到项目中的文件数量，您可能会得到稍微不同的结果，但仍然类似于图 5-8 。

图 5-8

已修改和未跟踪的文件会突出显示

我们要做的下一件事是将文件转移到提交中。添加更改后的文件和 filenottocommit.txt。

$ git add TODO.txt DONE.txt filenottocommit.txt

从上一章你知道，在提交之前，你应该总是检查你用“git diff - staged”准备了什么。但是让我们假设你忘记检查并立即提交。

$ git commit

即使这样，您也会看到提交消息屏幕，该屏幕概述了要提交的更改，如图 5-9 所示。

图 5-9

提交消息屏幕是最后一个安全措施

正如您所看到的，将要提交的更改和未跟踪的文件被概括和突出显示。很难错过它们，但是让我们假装错过，写一个简单的提交消息，保存，然后关闭编辑器。您将获得如图 5-10 所示的常规摘要。

图 5-10

提交摘要。我们搞砸了

现在您已经阅读了提交摘要，您注意到您提交了错误的文件，并且忘记提交另一个文件。

首先，您应该使用 git reset 从项目中删除最后一次提交。我们将使用“- soft”选项，以便我们所做的编辑保留在工作目录中。HEAD~1 表示前一次提交是对当前提交的引用。

$ git reset --soft HEAD~1

此后，您可以通过 git reset 再次卸载该文件:

$ git reset HEAD filenottocommit.txt

通过检查项目的当前状态，检查命令是否按预期工作。

$ git status

您将得到如图 5-11 所示的结果。

图 5-11

重置后项目的状态

如您所见，filenottocommit.txt 现在未被跟踪，因为我们已将其从临时区域中移除。自然，fileforgotten.txt 也没有被跟踪，因为我们没有登台。只有 DONE.txt 保留在临时区域，因为我们在提交后还没有接触过它。

警告

使用重置命令时要小心。非常危险。确保仔细检查你写的东西。

然后上演正确的。

$ git add fileforgotten.txt

现在您已经准备了正确的文件，您可以提交项目了。

$ git commit

在提交消息中放一个语法错误，这样您就可以看到 Git 的另一个特性。

修改提交

对于像提交消息中的错误这样的简单错误，没有必要修改整个提交。你只需要修改它。让我们试试我们的项目吧！

$ git commit --amend

修改过程看起来就像普通的提交，但是提交消息已经被写入，如图 5-12 所示。

图 5-12

编辑提交消息

您可以随意更改提交消息，然后像往常一样保存并关闭编辑器。

就这么简单！看一下新提交的名称，并将其与旧名称进行比较。你会注意到它们是不同的。这是因为提交名称是快照中信息的散列。因此，项目的不同状态会产生不同的名称。

关于修改提交的临别提示:不要滥用它！是的，写代码的时候犯错误并不理想，很多时候我们都想马上改正。但是错误也帮助我们变得更好；记录我们的错误是一种很好的学习方式。

练习:干净地修改提交

回到你的待办项目。本练习的目标是彻底修改提交。

• 编辑一些文件并登台。

• 提交它们，并在提交消息中犯一个语法错误。

• 取消文件登台。

• 上演另一出。

• 用正确的消息修改提交。

摘要

这一章主要讲述了导航、撤销和修改项目的版本。你现在应该对你提交的小修改没有问题了。一定要重读本章的第一部分，因为它对你在 Git 中做的所有事情都是必不可少的。你要把 Git 三种状态的区别背下来。

下一章很小，因为我们将只讨论理论。您将学习如何编写一个好的提交消息，在提交中包括和忽略什么，以及初学者会犯的常见错误。请务必仔细阅读下一章，因为它将对你和你的团队有很大的帮助。走吧！

六、Git 最佳实践

前一章是这本书最重要的一章。每次你对提交有疑问的时候，一定要回来看看。阅读完之后，您应该能够毫无问题地制作、检查和修改项目快照。既然您已经了解了 Git 的基本特性，那么是时候学习最佳实践来使您(和您的队友)的生活更加轻松了。这些是我希望在第一次使用 Git 时就知道的东西。我们将讨论提交消息，Git 的注意事项，以及初学者最常犯的错误。然后我们将以 Git 如何工作的一个小提示来结束。

提交消息

提交消息是版本控制最重要的方面之一，也是最容易被忽视的方面之一。这些消息可以帮助您(和其他人)理解提交中做了哪些更改，最重要的是，为什么要做这些更改。干净易读的提交消息对于更好的 Git 体验至关重要。让我们从确定问题开始。

Git 面临的最常见的问题是，提交消息通常没有意义，没有传达任何有意义的信息。大多数时候，每次提交的信息越来越不清晰。这是因为对 Git 概念的误解:每次提交都必须袖手旁观自身；如果一个提交需要其他提交才有意义，它就不应该存在。你不应该承诺一个半途而废的项目。如果一个任务变得太大，把它分成几个逻辑块，每个部分都有自己的意义。在拆分任务时，知道您是否在错误的路径中的一个好方法是检查可能的提交消息:如果您考虑使用非常相似的提交消息，您可能在拆分任务时犯了错误。例如，如果您的任务是在一个大型网站中进行许多小的修改，那么将它分成更小的任务是有意义的，比如提交每个页面或提交每个页面类别。所以记住:你的提交必须是独立的、原子的和完整的。

许多初学者也有一个问题，就是在提交消息中传递了太多的信息，从而用不必要的细节堵塞了大多数屏幕。提交消息必须简明扼要。你不需要告诉所有改变了的事情，你只需要解释为什么要做这些改变。如果有人想查看发生了什么变化，他们可以使用 git show 命令，该命令显示提交中发生变化的文件的完整摘要。

请记住，您不是唯一会阅读您的代码或文本的人。你必须花一点时间来解释这些变化的背景以及为什么要这样做。对自己说“我会记住的”是谎言，永远不要去实践。对于每一次提交，你应该问自己:“如果另一个人看着我的项目，他们会仅仅通过看我的提交消息就理解项目中变更的时间线吗？”也要记住，另一个人可能就是几个月后的你；密码很容易忘记。

底线是你的 Git 消息应该告诉你为什么要做这些改变。如果有人想知道发生了什么变化，他们可以查看 Git diff。

Git 提交最佳实践

为了获得更好的提交消息并避免前面列出的问题，这里有一些提示，您应该从现在开始遵循。这些建议会帮助你的同事，而且很有可能，在将来，你会清楚地知道为什么要犯错误。随着项目的进行，我们往往会忘记之前的步骤，所以在快节奏的开发中，拥有一个好的历史日志是必不可少的。

• 提交消息应该看起来很容易。

当您使用 git log 时，当消息太长时不会形成新行；因此用户必须滚动才能查看所有内容。这并不理想，因为您应该能够轻松地搜索和检索提交。

• 你写的信息不应该超过 50 个字符。

• 以大写字母开始信息。

• 不要以句号结尾。

• 利用现在的时间，扔掉不必要的文章。

• 提交消息应该一致。

因为 Git 消息在任何项目中都是基础，所以它们应该是一致的，并且不应该受到粗暴的改变。每次提交都应该使用相同的语言，并遵循其内部逻辑。在项目中期改变写作风格会使搜索提交变得非常困难。

• 这些信息必须清晰明了，并与上下文相关联。

当许多作者在不同的部分工作时，背景是大项目的关键。例如，许多开发人员通过变更所涉及的项目的上下文或区域开始他们的提交消息；但这只涉及非常大的项目。

不清楚或模糊的信息，如“更改 CSS”、“修复测试”、“热修复”、“小修复”和“更新”，应该不惜一切代价避免。它们经常误导用户，迫使用户去寻找不同之处。一定要包括为什么要做这些改变。永远不要强迫用户看你的代码变化来理解提交。

• 不要在细节上发疯。

您可以在主体中扩展您的提交消息，但是不要犯提供太多信息的错误。你唯一需要解释的是为什么要改变，而不是改变什么。

请记住:您的提交消息应该说明如果应用它，项目将会发生什么。所以你应该总是使用清晰的、现在时的、命令式的语言。最好的提交消息通常简短、直截了当、清晰明了。

没有比例子更好的方式来让它更清楚，所以让我们这样做。表格 6-1 是一个方便的工具，可以给你指出正确的方向。

表 6-1

最佳和最差提交消息的一些示例

|

最好的

|

严重的

|

最差的

| | --- | --- | --- | | [登录]修复数据库调用中的打字错误 | 修复了数据库调用中的打字错误 | 修复打字错误 | | 重构登录函数以便重用 | 通过将声明移动到参数来更改登录函数 | 代码重构 | | 为用户程序检查添加新的 API | 为用户程序检查添加新的 API | 新用户 API |

表 6-1 中给出的例子应该表明在编写提交消息时你是否处于良好的方向。

请注意，这些都是建议的行动，并不是一成不变的。如果真的有必要，你可以忽略其中的一些，如果这样能让信息更清晰的话。

做什么

让我们从列举使用 Git 时应该永远记住的良好实践开始。这对你的成功是必不可少的，因为它会为你节省一些时间。

要记住的最重要的事情是，提交是项目中独立的变更。您应该始终保持提交小且独立。提交的作用是(大部分时间)引入一个特性或修复一个 bug 它不是用来记录你所做的每一个改变。如果一个特性或错误修复需要大的独立步骤，那么将它们分成多次提交。例如，一个特性需要一个 API 端点和一个前端调用。没有必要在一次提交中完成所有这些更改，因为它们是独立的，没有任何逻辑联系。如果您在后端代码中犯了一个错误，您可以在不干扰前端代码的情况下恢复更改。通过多次提交来分隔它们还会使历史日志更易读，提交消息更清晰。

我们之前已经讨论过这个问题，但是因为它非常重要，所以让我们回头再讨论一下。每个提交消息必须回答“为什么？”为什么创建提交？它解决什么问题？请记住，在 Git 中，提交可以在许多用户之间交换。因此，提交消息必须回答这个问题:如果我选择并应用这个提交，它会做什么？这就是为什么提交时态应该是现在形式。很难摆脱用过去式写的需要，但是几个星期后，你应该会适应了。

就这样！使用 Git 要做的事情很少。只是要确保为你的小的、独立的提交写清楚信息。另一方面，不要做的事情列表如下。

不要做什么

这个列表比前一个列表长了一点。这是因为 Git 是一个非常强大的工具，它不会限制您可以做的事情。所以，犯错误是很容易的，尤其是当你认为这会节省你的时间的时候。不会的。糟糕的实践会给你带来更多的问题。最好是完全避免做那些事情。

大多数初学者容易犯的一个常见错误是一次提交解决多个问题。例如，当他们发现另一个 bug 时，他们正在修复一个 bug。他们解决了这两个问题，然后提交项目。这似乎很好，直到发现提交在代码库中引入了许多问题。因为只有一个提交，他们不知道是哪个更改导致了问题。这只是阻塞提交问题的一个方面。另一个原因是，它使得编写连贯清晰的提交消息变得困难。如果您发现自己在不同的上下文中提交了许多变更，那么可以考虑将这些提交分成更小的几个。

与前一个错误类似的另一个错误是合并没有任何共同点的提交。例如，代码重构不应该与错误修复或新特性在同一个提交中，而应该在它自己的提交中。这也是为了便于追踪 bug，并使历史日志更加清晰。

下一个错误来自对 Git 的根本性误用和一些公司的需求。就是把 Git 作为备份系统的错误。因为 Git 是一个分布式版本控制系统，所以存储库可以存储在远程服务器中。这促使一些开发人员在每天结束时提交他们的更改，不管这是否有意义。这也是因为需要显示您的日常进展，因为一些公司会查看生成的代码行数来衡量生产率。这是一种非常违反直觉的工作方式，因为它创建了许多试图解决同一问题的提交。它还会导致混乱的提交消息，随着时间的推移，这些消息越来越不清晰。不惜一切代价避免这种情况。你应该在工作准备好的时候提交，而不是因为你不得不提交。如果你需要提交，因为你的任务是做其他的事情，你将有机会借助分支或堆叠这样的概念来这样做。几章后你会学到这些。

Git 的另一个被滥用的特性是 amend 命令。避免修改提交来引入大的改变。修改应该只用于纠正错别字和添加忘记的文件或非常小的变化。如果变化太大，以至于您觉得有必要更新提交消息，只需再提交一次。但是这不是会把我的错误留在代码库中吗？是的，但是 Git 是用来跟踪版本和显示发生了什么变化的。你也需要记录你的错误，因为它们很容易忘记。不要为你的错误感到羞耻。试图抹去它们对任何人都没有帮助，当你再次面对同样的问题时，它会节省你很多时间。

这最后一个常见的错误已经在本书和无数电影中谈到过:永远不要试图改变历史。回到以前的版本并改变一些东西是非常诱人的。这是一个非常糟糕的想法，也是你能做的最危险的事情之一。如果你这样做，你的同事会讨厌你，你可能会把整个存储库搞得一团糟。改变某事的正确方法是重新承诺。过去的就过去了。放手吧。

注意

在本书的后面，你会学到如何回到过去，改变历史。我相信你永远不会这么做。

Git 如何工作(再次)

我知道，我知道。我们已经讨论过这个了。但是在我们进入这本书的第二部分之前，我想确定你已经完全适应了。

还记得 Git 的三种状态吗？它们也被称为三棵树(事实上这是文献中的官方称谓)。让我们再复习一遍。图 6-1 将帮助您快速识别树木。

图 6-1

Git 的三种状态之间的关系

如图 6-1 所示，这里没有什么新东西，只是提醒一下。要跟踪项目中的变更，您需要拍摄整个项目的快照。Git 不跟踪变化；它跟踪版本。

您将只与工作目录交互，因为在那里您的文件可以自由编辑。没有什么特别要说的:这只是你的文件的当前状态。

当您准备好拍摄项目的快照时，临时区域是您放置文件的地方。任何尚未放入临时区域(或临时索引)的已更改文件都不会成为快照的一部分。但是，这些更改仍然可以在工作目录中使用。因此，有必要在将文件添加到暂存索引之前和之后检查工作目录的状态，以确保一切正常。

存储库是 Git 架构的数据库。你会发现你所有的提交和历史记录。你可以在“中找到它。git”文件夹(除非要调整配置，否则永远不要碰它)。提交操作会获取临时区域中的所有内容，并对其进行快照。这就是为什么我们说“提交项目”，而不是“提交文件”或“提交更改”过去提交的未更改文件已经在临时区域中。这就是为什么你不需要把所有东西都放在舞台上，只需要编辑好的文件。记住也要存放新的或删除的文件！

最后，签出会将项目的状态带回到之前的状态。工作目录将会改变以反映这些变化，所以确保没有任何未提交的文件。

所以使用 Git 的基本步骤是

• (在工作目录中)进行更改

• 转移每个已更改的文件(在转移索引中)

• 提交项目(在存储库中)

就这么简单，但是在进入下一章之前，请务必理解这些状态之间的关系。本节之后的每一节都假设您对这些内容很熟悉。

但是提交在存储库中是什么样子的呢？很简单:它们看起来像链表。提交包含许多信息:内容和元数据。内容只是项目文件(更改的文件和对未更改文件的引用)。元数据包含其他非常重要的数据:提交日期、提交者身份和 Git 消息。提交中存在的另一个元数据是父指针或引用。它只是前一次提交的名称；如果为空，则意味着提交是第一个。因此，每个提交都以父子关系链接到下一个提交。

警告

由于提交的名称是通过散列其内容和元数据获得的，因此更改其中之一将导致名称的更改。如果名称更改，下一次提交将不会指向任何父对象，因为它的元数据中有父引用。这就是为什么改变历史是非常危险的。千万不要做。

摘要

这是一个充满概念和术语的章节。它不像其他的那么专业，但是它对你使用 Git 的成功至关重要。您现在应该知道什么时候是提交的正确时间，以及如何编写有用的提交消息。记住:你的目标是让跟踪项目变更变得更容易。提交消息应该足够清楚地回答这个问题:提交带来了什么？不要忘记历史日志也可能被非开发团队成员阅读。

要记住的主要事情是提交是你项目的基础，所以，每一个都必须是稳定和独立的。您的提交消息应该总是解释提交存在的原因，而不是做了什么。

这一章也有很多关于 Git 的注意事项。试着记住这些，因为它会节省你无数的调试时间。

这也是本书第一部分的结论。我们将要学习一个非常有用的工具:GitHub。我们至少可以分享和追踪我们的项目。您可能想知道我之前向您承诺的 Git 特性。不用担心；他们将在这部分之后来。我知道你很想开始，所以我们走吧！

七、远程 Git

恭喜你完成了这本书的第一部分！现在，好戏开始了。第一部分向您介绍了 Git 的基本特性。您应该能够轻松地使用 Git 进行更改和跟踪。编写有意义的提交消息有点困难，但是如果你遵循上一章的建议，每次提交都会变得更好。您还应该能够查看以前的版本并查看历史日志；这些是所有后续章节需要的非常重要的特性。

现在，您已经准备好应对一个全新的挑战:离开您的本地存储库，使用远程存储库。在这一章中，你将学习为什么远程工作很重要，最重要的是，它是如何工作的。还将向您介绍典型的团队工作流程以及如何正确使用远程存储库。由于远程 Git 的概念有一点挑战性，您将看到一个简单的工具，它将在整个过程中对您有很大的帮助(提示:这是本书的名称)。我们上网吧！

为什么要远程工作

从本书开始，我们只在本地库上单独工作。但是 Git 是一个很好的团队合作工具；如果只在本地存储库上使用它，那就太可惜了。在这一节中，我们将看到什么是远程 Git，以及为什么有人想要使用它。

在本书的开头，我说过 Git 是一个分布式版本控制系统。这意味着存储库不是存储在单个服务器上，而是存储在许多本地存储库中。每个客户端都有自己的本地存储库，包含自己的提交和历史记录。这些提交可以自由交换，并且所有文件都可以随时编辑。这就是 Git 设法支持团队工作的方式。

因为团队工作是基于提交交换的，所以必须找到一种方法来确保所有的提交在任何时候都是可用的。在访问他们的提交之前，等待你的同事到达工作地点并启动他们的计算机是非常不方便的。显而易见的解决方案是让一个服务器托管存储库，每个人只需从它那里推和拉提交。但是这不是危险地接近 VCS 中心的工作流程吗？一点也不(嗯，有一点)。正如我们之前所讨论的，分布式 VCS 的创建是为了避免拥有中央存储库所带来的问题。每个客户都有自己的存储库，他们可以在任何需要的时候使用它；几乎所有的 Git 操作都是在本地完成的。远程服务器只是被指定为一个客户端，它有一个存储库，每个人都可以在那里提交他们的提交。这样，每个人都可以随时看到所有的更改。这种工作方式只是用来促进提交交换；它没有内置到 Git 中。对于 Git，所有的存储库都是平等的。开发人员只是认为一些存储库比其他的更平等。

注意

不需要中间服务器就可以共享提交。但这是一个如此糟糕的想法，我们甚至不会在这本书里教它。

即使您独自工作，除了本地存储库之外，拥有远程存储库仍然是一个好主意。这样，您就可以在一个安全的位置备份项目及其所有历史记录。您还可以随时访问您的项目，前提是您可以通过网络访问存储库所在的服务器。

警告

正如我们在上一章中所说的，仅仅因为 Git 可以用作备份系统并不能使它成为备份系统。将它用于这一唯一目的并不是一个好主意。

那么，你对那个远程存储库感兴趣吗？你当然是，太神奇了！让我们看看它是如何工作的。

它是如何工作的

使用远程服务器只是让一台计算机保存您的项目及其历史的副本。你不需要把你所有的提交都推给它，你只需要把你想分享的提交推给它。然后，您的同事提取他们感兴趣的提交，并将它们应用到他们自己的存储库中。基本上就是这样了！您使用远程服务器来复制存储库并推送和提取更改。让我们详细看看这一切是如何工作的。

要建立一个远程存储库，您首先需要一个能够运行 Git 软件的服务器。任何称职的计算机都可以运行 Git，因为它是一个非常小的软件。你也不需要很大的火力来正常运行它。即使像 Raspberry Pi 这样非常小的计算机对 Git 来说也绰绰有余。

现在您已经有了服务器，您必须找到一种与它通信的方法。对服务器的网络访问是必要的，以便多个客户机可以在同一个存储库之间进行推和拉。与服务器的通信应该非常安全。如果能够访问服务器的任何人都可以阅读和编辑存储库，那将是非常令人失望的。为了能够与存储库交互，用户必须在每次 Git 操作中验证自己。可以使用登录/密码 HTTPS 类型的认证，但是因为认证必须在每个操作之前，所以它会很快变得很累。对此的解决方案是使用 SSH 认证。SSH 验证的原理很简单:只有预先确定的客户机才能访问存储库。

基本上就是这样了！设置远程 Git 服务器是一项非常简单的任务。另一方面，维护和保护它…

注意

就像之前一样，Git 没有区分“服务器”和“客户端”它们只是开发者强加的社会结构。

如果您独自工作或者希望保持项目的私密性，那么使用您自己的服务器来托管您的 Git 项目是一个好主意。然而，当你和一个团队一起工作时，这就成了一种痛苦。每个团队成员必须能够通过网络访问 Git 服务器，所以如果您的团队在同一个工作空间，您需要建立一个本地网络。服务器还应该全天候运行，这样 Git 操作就不会有延迟。

如果你的一些同事在异地或不同的工作场所，会发生什么？嗯，你需要把你的服务器连上互联网。因此，你也需要提高你的安全游戏。您的同事越多，您需要管理的身份验证异常就越多。

使用你自己的 Git 服务器的另一个问题是你需要处理权限。正如在第一章中所看到的，并不是所有的开发人员都应该拥有对存储库的写权限。例如，初级成员在提交到存储库之前，需要由高级成员审查他们的提交。给他们直接访问项目是一个坏主意(因为他们贪得无厌地需要改变历史)。

这些都是维护自己的 Git 服务器所带来的问题。如果有一种工具可以帮我们处理这些事情就好了…

简单的方法

你猜怎么着？有一个工具可以帮我们处理所有这些事情！它的名字叫 GitHub！GitHub 是处理远程存储库时的首选工具；您可以将 GitHub 视为使用 Git 的项目的代码托管服务器。它就像你自己的 Git 服务器一样工作，但是没有那么麻烦。

它创建于 2008 年，用于托管 Git 项目，现在是微软的子公司，微软一直在开源社区投入大量资金。图 7-1 显示了他们在 github.com 的主页。

图 7-1

GitHub 主页

现在来说说数字。GitHub 拥有超过 3600 万用户构建的超过 1 亿个存储库。如图 7-2 所示，他们对这些数字感到非常自豪。

图 7-2

GitHub 的用户

GitHub 几乎涵盖了开发人员的所有需求，无论是希望共享软件的开源开发人员，还是希望不用自己的服务器就能私下工作的专业团队。

几乎像一个社交媒体，GitHub 也为开发者提供了一个空间来构建、分享和记录他们的项目。不再需要外部工具或网站。对于开源项目来说，GitHub 也是一个非常重要的工具，因为它旨在促进开发者关系和代码发布。用户可以查看彼此项目并提出更改建议。您甚至可以关注和贡献您最喜爱的存储库！

而且不限于开源项目！公司和开发者也可以创建私有存储库，只有他们可以访问。他们受益于 Git 的常用特性，但还不止这些。这就是 GitHub 如此受欢迎的原因:每个人都有适合自己的东西！

也有很多软件公司提供与 GitHub 非常相似的服务，最受欢迎的是 GitLab 和 BitBucket。

GitLab 的大部分功能与 GitHub 非常相似，有两个版本:社区版和企业版。GitLab Community Edition 是开源的，与 GitHub 非常相似，你可以毫无问题地阅读这本书的全部内容。GitLab 在 DevOps 圈子里也是很受推崇的，所以如果你对那个职业道路感兴趣，一定要去看看。

BitBucket 最初是为了托管 Mercurial 项目而创建的，自 2011 年以来，它增加了对 Git 项目的支持。由 Atlassian 开发，其业务模型与 Git 非常相似，并且提供相同的企业利益。

使用本地服务器有利也有弊；但是缺点的数量是如此之多，以至于我们将在本书中选择简单的方法。然而，您至少应该知道远程存储库是如何工作的，以及为什么需要它。如果你仍然想使用你自己的服务器，在这本书的一个附件里有一个关于如何做的指南。玩得开心，☺

摘要

本章只是远程存储库的一个非常简单的介绍。在本地工作很有趣，但团队合作需要分享你精心制作的承诺。您可以在自己选择的远程服务器上托管您的 Git 存储库，但是最简单的方法是使用 GitHub 这样的专门托管代码的服务。

但是 GitHub 做的远不止这些！在下一章，我们将详细讨论它的主要特性是什么，以及我们如何利用它们。我们将学习错误跟踪、访问控制、特性请求等等。让我们继续前进！

八、Github 优先

在上一章中，我们初步发现了远程存储库及其重要性。你也应该对它们的工作原理有一个基本的了解，最重要的是，使用它们有什么好处。现在，我们来谈谈最著名的代码托管平台:GitHub。

首先，我们将介绍 GitHub 的简短历史，以便更好地了解它。然后，我们再来说说使用 GitHub 的是什么样的人，他们用它来做什么。

GitHub 概述

给 GitHub 下一个定义真的很难，因为它同时做这么多事情。所以，我就用它自己的话说:“GitHub 是一个受你工作方式启发的开发平台。从开源到商业，你可以托管和审查代码，管理项目，与 3600 万开发人员一起构建软件。”

因此，GitHub 不仅是一个代码托管平台，还是一个开发平台。这是什么意思？它意味着你不仅仅使用 GitHub 来存储你的代码；你用它来计划和追踪它的进化。我们将在下一节看到它的所有特性，但是要记住的主要事情是 GitHub 可以帮助你构建和发布你的项目。

如果你使用 GitHub 只需要一个理由，那就是它提供的开发工作流程。项目经理将所有未完成的任务写在白板上，团队成员互相发送电子邮件来跟踪谁在做什么的日子已经一去不复返了。也不需要一长串来回的电子邮件来检查任务的进度。所有这些都由 GitHub 管理。

GitHub 和开源

GitHub 一直是开源项目的亲密盟友；事实上，GitHub 是世界上最大的开源社区的所在地。由于开发人员需要一个方便的地方来构建和共享他们的项目，GitHub 是一个显而易见的选择。这样，任何人都可以咨询和参与关于项目的所有决策和讨论；这就是开源的美妙之处。

有了 GitHub，对一个开源项目来说，你能做的最好的事情比以往任何时候都要简单:贡献。当你发现一个你喜欢的项目时，你可以像在社交媒体上一样关注它，并看到它的进展。如果你想开发一个新的特性或者修复一个 bug，你只需要做一个项目的克隆，然后在上面工作。这个过程被称为“分叉”，它是开源项目的支柱。当您完成了对项目副本的所有更改后，您可以向项目的维护者提交一个 Pull 请求(PR)。这意味着您正在请求您所做的变更被提取并合并到项目中。然后，其他参与者将检查您的更改，并可能要求一些其他更改。所有这些都在 GitHub 上完成，而不是通过电子邮件或即时消息进行交流。在所有各方就变更达成一致后，拉取请求被接受，您的变更现在是项目的一部分了！

当然，开源项目不仅仅是代码；他们需要文档、翻译、社区经理、维护人员等等。您可以通过编写文档和提供翻译，甚至审查其他贡献者所做的更改来为项目做出贡献。项目还需要测试人员和能够对最终产品提供见解的人。它们是有数百万贡献者的项目，所以需要社区管理者。他们对社区的福祉负责，并被期望执行社区的内部行为准则。一些贡献者的任务是欢迎和辅导初学者，这对任何项目来说都是困难但非常必要的。

GitHub 被数以百万计的开源项目所选择，因为从想法到发布的工作流程是如此的简单和容易。派生一个项目来为它做贡献的概念是任何开源项目的主要驱动力。如果你喜欢一个项目，但不喜欢它的发展方向；你可以叉起它，开始你自己风格的项目。然后，您将成为新项目的维护者，如果其他人想要做贡献，他们可以向您提交 Pull 请求。因此，任何人都是幸福的！

正如以前建立的那样，开源项目需要文档和初学者教程。对于小型项目，一个文本文件(习惯上称为 README)就足够了。自述文件应该介绍项目，并传达它解决了哪些问题。它还应该告诉用户如何安装和使用它，以及如何为它做出贡献。您可以查看图 8-1 中的自述文件示例(您也可以查看 https://github.com/git/git )。

图 8-1

Git 的自述文件

如图 8-1 所示，自述文件可以有基本的文本格式和链接。它们还可以包括图像和代码示例。

大项目需要的不仅仅是自述文件，因为它们需要被恰当地呈现和记录。GitHub 项目有一个名为“wiki”的部分是专门为这些需求定制的。就像所有的维基一样(它是从维基百科模仿来的)，GitHub 维基帮助新来者理解这个项目是如何工作的。许多 wikis 也有一个名为“常见问题”的部分，其中回答了最常见的用户查询。通常，wikis 用于文档和教程太长而不适合自述文件的项目。你可以在图 8-2 中看到一个维基页面的例子，你也可以在 https://github.com/Dash-Industry-Forum/dash.js/wiki 找到；注意所有链接都出现在侧边栏。

图 8-2

提供文档的 wiki

因为文档在开源项目中非常重要，所以编写文档并保持更新是许多贡献者的工作。请记住，wikis 也是 Git 存储库，因此对它所做的更改也会像任何存储库一样被跟踪。这样做是为了将开发工作流与文档工作流分开。

最重要的是，自述文件和维基是用一种叫做 Markdown 的标记语言编写的。这是一种非常简单的语言，可以呈现简单的格式和链接。你可以在图 8-3 中看到一个例子。但是你也可以选择用 HTML 写所有的东西，而不是转换成 Markdown。你还会在这本书的附录中找到一份减价备忘单。

图 8-3

降价示例

开源项目的繁荣还需要一件小事:市场营销。是的，README 文件和 wikis 对开发人员来说是很好的资源，但是最终用户可能不会觉得它们太有帮助。这就是为什么许多项目都有一个专门吸引用户使用他们产品的网站。网站也是一个为自己扬名并展示自己的好方法。如果一个项目没有网站或者没有被搜索引擎引用，它被最终用户发现的机会就很小。尽管如此，维护和托管一个网站并不是一件容易的事情；从金钱的角度来看，它甚至可能是昂贵的。许多开源项目没有一个好的营销活动所必需的资源；他们主要依靠搜索引擎的点击率和口碑。这就是 GitHub Pages 存在的原因。GitHub Pages 只是一个直接托管在您的存储库上的网站；你可以用它来展示你的产品，提供教程，或者任何你想要的东西，真的。它摆脱了创建网站和托管网站的麻烦。但是这不会干扰代码吗？一点也不，像维基一样，GitHub 页面存在于存储库的其他部分；所以他们可以有不同的贡献者。你可以查看图 8-4 中一个托管在 https://scd-aix-marseille-universite.github.io/latexamu/ 上的 GitHub 页面的例子。如你所见，这只是一个简单的网站，但直接托管在 GitHub 上。它不仅限于简单的演示网站；你也可以建立博客和类似的网站。您将在附录中看到如何构建 GitHub 页面。☺

图 8-4

GitHub 页面示例

如你所见，GitHub 为开源社区提供了很多东西。所有这些都是免费的！但是现在，让我们来看看 GitHub 能为你个人提供什么。

个人使用

是的，开源是伟大的，但什么是不是你果酱？或者当你有一个你想保密的项目时？GitHub 也覆盖了你！

你不必公开你所有的 GitHub 库；还有一个选项是将它们设为私有。这样，只有你和少数合作者(你选择的)可以访问它。您可以在 GitHub 上创建无限数量的公共和私有存储库；唯一的限制是你的创造力和时间。然而，私有存储库的贡献者数量是有限制的:3。如果你想与更多的贡献者合作，你可以注册 GitHub Pro，这是一个付费计划。但是对于几乎所有人来说，免费计划已经足够了。

拥有一个个人 GitHub 账户来展示你的作品也是推销自己的好方法。这样，人们可以检查你贡献的开源或个人项目，甚至检查你的代码。许多开发人员也使用 GitHub 页面来呈现他们的简历或展示他们的作品集。你可以查看图 8-5 中的例子。

图 8-5

一个随机的人的 GitHub 页面

由于 GitHub 上有 3600 万开发者，你可能想和他们中的一些人联系。一种联系方式是关注一个特定的项目。当项目进行的时候，您将会收到更新，并且可以检查变更。请注意，您将自动跟踪您所贡献的存储库。另一种表达你对一个项目的欣赏的方式也是给它打“星”。这类似于喜欢社交媒体上的内容。因此，存储库的星级越多，用户就越满意。GitHub 还提供了一个新闻提要，即来自特定项目的新闻和通知。那些项目被选中是因为你为它们做出了贡献或者“主演”了它们。它们也是通过分析你最常用的语言或工具而量身定制的。您可以查看图 8-6 中的示例。这是对你周围发生的事情有一个清晰的认识的好方法。

图 8-6

GitHub 探索

在我们进入下一部分之前，有一个很酷的东西你可以用 GitHub 查看:你的贡献活动。你在 GitHub 上的每一次提交都会被注册为一个贡献，如果你启用了这个选项，甚至会被注册到你的个人或私有存储库中。这些活动以类似于图 8-7 所示的漂亮插图呈现。它们展示了你一年来的贡献，并向你个人资料的访问者展示了你的成就。

图 8-7

2018 年我的投稿历史

面向企业的 GitHub

GitHub 不只是针对个人项目或开源社区；企业在那里也有一席之地。现在许多企业都投资开源产品，还有比 GitHub 更好的地方可以找到高质量的开发者吗？

GitHub 中有一个企业计划，它包含了付费计划的所有好处，但还有许多附加功能。这些功能包括从主机选择、安全性到在线支持。所有这些功能可能对企业非常有吸引力，但对我们来说，一个简单的免费计划就足够了。

摘要

本章介绍了 GitHub 的用户和一些小功能。你现在应该对你要用它做什么有一些想法了。在下一章，GitHub 的主要特性将会和一些关于如何使用它和队友一起工作的技巧一起呈现。我们将讨论项目管理、代码审查等等。最后，我们将从 GitHub 的第一个存储库开始。你将在下一章回到行动中，所以一定要复习前面的练习以保持敏锐。开始吧！

九、GitHub 快速入门

到目前为止，我们只讨论了什么是 GitHub，谁需要它。现在，我们要看看它到底能做什么，它的主要特点是什么。GitHub 最重要的特性是它的项目管理工具；与正确的开发工作流程相结合，这是让项目向前发展的可靠方法。

对于这一节的书，没有什么比好的老式练习更好的了！我可以告诉你 GitHub 的所有优点，但是如果你自己去探索，你会理解得更好。让我们首先创建一个 GitHub 帐户并开始一个项目。

项目管理

GitHub 最令人钦佩的特性之一是能够在遵循既定路线的同时管理项目。在这一部分你要跟着我。这样做非常重要，因为您将对这些功能有更好的理解。

因为我们要用 Git 和 GitHub 管理我们的项目，所以我们的第一步是创建一个帐户。这非常简单，除了您的姓名和电子邮件之外，您不需要任何其他信息，如图 9-1 。

图 9-1

GitHub 签名页

注册后，你会在你的电子邮件客户端收到一个确认链接，按照提供的链接将结束铭文。然后你将到达 GitHub 主页面，看起来应该如图 9-2 所示。

图 9-2

GitHub 主页

你的 GitHub 主页很空，但是我们正在用很酷的项目填充它。在页面的右边，你会看到一些趋势库或新闻故事；但我们还不会去那里。

正如您在图 9-2 中看到的，您可以通过三个链接来创建新的存储库:一个在左侧，一个在中间，最后一个在导航栏中。单击其中一个，这样我们就可以创建我们的存储库。

存储库的创建形式也非常简单，如图 9-3 所示。您只需要在表单中填写项目的名称和简短描述。这个描述是可选的，但是您应该尽量使它简单，以便访问您的存储库的用户知道发生了什么。

图 9-3

创建新的存储库

如果您愿意，您可以选择将存储库设为私有；除了你，没有人能接触到它。公共知识库并不意味着任何人都可以编辑它；这只是意味着任何人都可以阅读它，并且登录的用户可以对它提出修改。您仍然是项目的维护者和存储库的所有者。

然后，您可以选择用自述文件初始化存储库。现在忽略这一点，因为我们的目标是从头创建一个存储库；我们将添加自述文件。gitignore，以后再许可文件。

完成所有工作后，单击 Submit 按钮创建您的第一个 GitHub 库！就这么简单！然后，您将被重定向到您的项目页面，这是到您的存储库的唯一链接。链接是这样的:https://github.com/your_username/your_repository；例如，我创建的新存储库可以通过下面的链接访问: https://github.com/mtsitoara/todo-list 。因此，您不能创建两个同名的存储库。您的项目页面应该类似于图 9-4 中所示的页面。

图 9-4

你全新的仓库

正如您在图 9-4 中所看到的，无论您想要创建一个新的存储库还是推送一个现有的存储库，都有一些关于如何开始的说明。因为我们正在从头开始构建我们的存储库，所以我们将选择第一个选项。第二个选项对我们来说也是可行的，因为我们已经有了一个本地存储库，但是从现在开始我们将忽略它。

因此，我们创建了第一个存储库，并准备在其上推进我们的项目。但是让我们看看这个神奇的盒子，看看到底发生了什么。

远程存储库如何工作

还记得第七章关于远程 Git 以及我们如何决定使用 GitHub 作为远程存储库吗？这一节是那一章的逻辑延伸，因为我们将学习如何使用 GitHub 管理远程存储库。

当我们使用 GitHub 网站创建存储库时，我们向 GitHub 服务器发出指令，要求它们初始化一个空的存储库。如果你还记得第二章的话，初始化一个存储库非常简单:转到任意目录并执行 git init。这正是这里发生的事情，只不过不是在你的电脑上，而是在 GitHub 托管的服务器上。

因此，就好像我们在安装了 git 的远程服务器上执行了以下命令

$ mkdir todo-list

$ cd todo-list

$ git init

我们将使用相同的命令来创建本地存储库。所以现在，GitHub 的服务器中有一个远程存储库，我们将使用它来共享我们的项目。

使用远程存储库，因此您不必使用自己的电脑来共享您的项目。就 GitHub 而言，任何人都可以访问远程存储库，但只有所有者可以编辑它们。我们将在后面的部分讨论团队合作。

主要的好处是远程存储库是您可以发布项目的地方，以便每个人都可以使用它。任何人都可以克隆您的存储库，因此他们可以跟踪您的进步以获得最新的更改。

将您的本地存储库发布到远程存储库称为“推送”，将最新提交从远程存储库获取到本地存储库称为“拉取”Push 和 pull 可能是 Git 中最常用的命令。

但是我如何告诉 GitHub 我希望哪个远程存储库与我的本地存储库相链接呢？这就是需要到您的存储库的唯一链接的地方。您将使用该链接来推送您的本地更改或拉取您还没有的提交。

总之，GitHub 创建了一个空的远程存储库，它只能由您修改，但每个人都可以看到。我们现在需要做的是创建一个本地存储库，并将其链接到远程存储库。

链接存储库

既然 GitHub 已经为我们创建了远程存储库，那么是时候创建我们自己的本地存储库并将其链接到远程存储库了。

正如我们在前面章节中所做的，我们将使用 git init 命令创建一个存储库。本地和远程的存储库名称可以不同，但是最好使用唯一的名称，以免混淆。对于这个特定的项目，命令将是

$ mkdir todo-list

$ cd todo-list

$ git init

注意

如果您喜欢使用您在本章前面创建的存储库，而不是一个新的存储库，您可以跳过初始化部分，直接进入链接。

这里没什么新鲜的；并且你应该得到如图 9-5 所示的相同结果。

图 9-5

Git 存储库的初始化

现在我们有了本地存储库，是时候将它链接到远程存储库了！要列出、添加或删除远程，我们将使用 git remote 命令。例如，让我们使用以下命令链接当前的遥控器:

$ git remote

你不应该得到任何结果，因为这是一个全新的存储库，我们没有链接任何远程到它。现在再加一个吧。

注意

如果您在结果中看到远程，您可以使用 git remote rm [remote_name]删除它们。无论如何，如果它是一个新的存储库，您不应该看到任何远程。

您将需要到您的存储库的唯一链接，以便能够将本地存储库链接到它；所以，从上一节中拿起你的。我的是 https://github.com/mtsitoara/todo-list.git 。不要忘记。最后 git！

您还需要为您的远程存储库创建一个名称。这样，您可以在一个项目中拥有多个遥控器。在测试和生产远程互不相同的情况下，这可能是必要的。按照惯例，默认名称是“origin”。虽然您可以选择任何名称，但建议使用 origin 作为队友共享工作的遥控器的名称。

向遥控器添加链接的命令很简单。它是

git remote add [name] [link]

因此，要向新创建的存储库添加链接，您必须执行以下命令:

$ git remote add origin https://github.com/mtsitoara/todo-list.git

就这样！您可以通过执行 git remote 或 git remote -v 来获得更多信息，从而检查是否添加了远程。您应该会得到类似于图 9-6 所示屏幕的结果。

图 9-6

添加新遥控器

就这样！添加新遥控器是一项简单直接的任务。现在我们清楚了这一点，让我们把这个项目推向 GitHub 吧！

推送到远程存储库

我们最终将本地和远程存储库连接起来。是时候把我们的项目推到 GitHub 上了，这样我们就可以分享我们的工作了。

将提交推送到远程存储库非常简单；但是首先，让我们创建一些要推送的提交。在您的工作目录中，创建一个名为 README.md 的文件，并在 Markdown 中放入您的项目描述。例如，下面是我的 README.md 文件:

# TODO list
A simple app to manage your daily tasks

## Features
* List of daily tasks

现在，让我们使用 git add 将新创建的文件添加到临时区域。

$ git add README.md

现在是时候用 git commit 提交我们的项目了。对于提交消息，许多开发人员在第一次提交时选择“初始提交”。这不是一个规则，如果你想的话，你可以改变它。

$ git commit

因为我们已经做了很多次了，现在你应该对准备和提交已经很熟悉了。提交之后，您应该会得到类似于图 9-7 的结果。

图 9-7

创建、暂存新文件

所以，我们有了第一次提交！现在，我们可以将这些更改推送到远程存储库。将更改推送到远程的命令很简单；您只需要远程存储库的名称和要推送的分支。因为我们还没有创建任何分支(我们将在后面的章节中学习分支)，所以我们唯一的分支叫做“master”git push 命令是

git push <remote_name> <branch_name>

因此，在我们的例子中，命令将是

$ git push origin master

有一点点运气，一切顺利；但事实并非总是如此。如果你使用一个密码管理器或者使用不同于你提供给 GitHub 的配置(名字和电子邮件),你会遇到一个认证问题。例如，我被拒绝访问我的存储库，因为我使用了密码管理器，它试图用我的旧凭证登录我。您可以查看图 9-8 中的验证错误示例。

图 9-8

认证错误

为了解决这类问题，我们必须用正确的信息重新配置 Git。您可以在图 9-9 中看到，我在全局配置中更改了我的电子邮件，也就是说，在我计算机上的每个存储库中。

图 9-9

Git 的重新配置

现在，我们必须确保删除该存储库中任何指向密码管理器的链接。对于我的情况，我在这台计算机上的其他存储库中使用凭证助手(密码管理器)；所以我不会设置一个全局配置，而是设置一个本地配置。

$ git config --local credential.helper ""

这应该解决了我们的问题，我们可以继续努力。在执行 git push 命令之后，将会要求您输入用户名和密码。然后，你会得到一个类似于图 9-10 的结果。

图 9-10

成功的 git 推送

小费

因为我们使用 HTTPS 来推送和拉取更改，所以每次都需要提供我们的用户名和密码。它很快就会变得很累，所以如果你想使用密码管理器或者完全停止使用密码，请查阅本书附录中的课程。

现在，每个人都可以在 GitHub 上看到我们的项目！让我们在它的项目页面上查看一下。如果我们刷新项目页面，我们应该得到如图 9-11 所示的页面。

图 9-11

更新的项目页面

如图 9-11 所示，存储库页面现在显示了许多英特尔:

• 提交的次数

• 最后一个提交名称及其提交者

• 所有项目文件的列表

• README.md 的预览

我们刚刚做的是代码共享的基础:推动改变。在使用远程存储库时，您将会反复使用这个命令。这是一个非常简单的特性，但是您必须完全理解它的作用。推送仅仅意味着将所有当前提交(在特定分支中)复制到远程存储库中的远程分支。所有历史记录也会被复制。

在进入下一章之前，问自己这些问题:远程存储库存储在哪里？谁对它们有只读访问权限？谁可以编辑它们？还要确保理解远程和本地存储库链接的基础以及为什么它是必要的。

摘要

在这一章中，我们第一次与远程 Git 库进行了交互。正如我们已经建立的，它们只是普通的存储库，存储在远程服务器上，而不是本地机器上。我们看到了如何创建和链接本地和远程存储库，这个特性我们会经常用到。我们学习的主要命令是 git push，它将本地存储库的状态复制到远程存储库。

在下一章，我们将深入项目管理，看看 GitHub 还能提供什么功能。我们还将学习从远程存储库中提取变更，以及解决推送和提取问题。我们走吧！