Git 诞生于一个极富纷争大举创新的年代。Linux 内核开源项目有着为数众广的参与者。绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002年间）。到 2002 年，整个项目组开始启用分布式版本控制系统 BitKeeper 来管理和维护代码。
到了 2005 年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了免费使用 BitKeeper 的权力。这就迫使 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds ）不得不吸取教训，只有开发一套属于自己的版本控制系统才不至于重蹈覆辙。他们对新的系统制订了若干目标：
- 速度
- 简单的设计
- 对非线性开发模式的强力支持（允许上千个并行开发的分支）
- 完全分布式
- 有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）
自诞生于 2005 年以来，Git 日臻成熟完善，在高度易用的同时，仍然保留着初期设定的目标。它的速度飞快，极其适合管理大项目，它还有着令人难以置信的非线性分支管理系统（见第三章），可以应付各种复杂的项目开发需求。
Git 是一个分布式的版本控制和源代码管理系统，强调速度。 Git 最初由Linus Torvalds设计和开发为Linux内核开发管理代码。 Git是GNU通用公共许可证版本2的条款下分发的免费软件。
本教程将教你如何使用Git 在你的项目版本控制在分布式环境中的基于 Web 和非基于Web 应用程序的开发工作。
对于初学者来说已经准备本教程，帮助他们了解Git版本控制系统的基本功能。完成本教程后，可以把帮助你熟悉和使用Git版本控制系统。
我们假设你要使用 Git 来处理各级 Java 和非Java项目。所以如果你有知识，开发的基于 Web 和非基于 Web 的应用程序的软件开发生命周期和知识，将有助于学习和使用Git。
版本控制系统 (VCS) 是软件，帮助软件开发人员携手合作，他们的工作并保持完整的历史。
以下是VCS目标
- 允许开发人员同步工作.
- 不要覆盖对方的变化.
- 维护历史的每一个版本.
以下是常见的VCS
- 集中式版本控制系统（CVCS）
- 分散式/分布式版本控制系统（DVCS）
在这个教程，我们将介绍集中分布式的版本控制系统，尤其是Git。 Git 属于分布式版本控制系统。
集中式版本控制系统采用中央服务器上存储的所有文件和实现团队协作。但是CVCS主要缺点是中央服务器的单点故障，即故障。不幸的是，如果中央服务器宕机一小时，然后在该时段没有人可以合作。即使在最坏的情况下，如果中央服务器的磁盘被损坏，并没有采取适当的备份，那么将失去整个项目的历史。
DVCS客户不仅检出的最新快照目录，但他们也完全反映资源库。如果SEVER停机，然后从任何客户端库可以复制回服务器，以恢复它。每个结账是完整的版本库备份。 Git不会依赖中央服务器，这就是为什么可以执行许多操作，当处于脱机状态。可以提交修改，创建分支视图日志和执行其他操作，当处于脱机状态。只需要网络连接，发布您的更改，并采用最新变化。
Git是GPL开源许可证下发布的。它可自由在互联网上。可以使用Git来管理项目无需支付一分钱。由于它是开源的，可以下载它的源代码，并根据要求进行更改。
由于大部分的操作都在本地执行，它给人带来巨大的好处，在速度方面。 Git 不依赖于中央服务器，为什么每一个操作就没有必要与远程服务器进行交互。 Git核心部分是写在C中，从而避免了与其他高级语言的运行时开销。虽然 Git中反映整个存储库，在客户端上的数据的大小是小的。这说明它是在客户端上的数据压缩和存储的效率有多高。
丢失数据的机会是非常罕见的，当有多个副本。存在于任何客户端的数据存储库中，因此它可以被用来在发生崩溃或磁盘损坏的镜像。
Git使用常见的加密散列函数，称为安全的哈希算法（SHA1）命名，并确定在其数据库中的对象。每一个文件并提交检查总结和检索其校验在结账的时候。意思是说，这是不可能改变文件，日期，提交信息和且从Git 数据库不知道Git 任何其他数据。
在CVCS情况下，中心服务器需要足够强大，要求整个团队服务。对于较小的团队，这是不是一个问题，但随着团队规模的增长，服务器的硬件限制可能成为一个性能瓶颈。在DVCS开发的情况下不与服务器进行交互，除非他们需要推或拉的变化。所有繁重发生在客户端上，所以服务器硬件可以是很简单的。
CVCS使用廉价的复制机制，这意味着如果我们创建新的分支，它会复制到新分支的所有代码，所以它的耗时和效率不高。另外CVCS的分支的删除和合并是复杂和费时的。但是，使用Git分支管理是很简单的。只需要几秒钟，创建，删除和合并分支。
- 自由和开放源码
- 快速和小
- 隐式备份
- 安全
- 不需要强大的硬件
- 更简单的分支
每个VCS工具提供私有工作场所的工作副本。开发者在他的私人工作场所的变化，并提交这些更改后成为仓库的一部分。 Git的需要这一步，为他们提供的专用副本是整个仓库。用户可以执行许多操作，这个库中，如添加文件，删除文件，重命名文件，移动文件，提交改变，还有更多。
工作目录是地方文件检出。其他CVCS开发商一般不修改，并承诺他的变化，直接向版本库。但Git使用不同的策略。 Git不会跟踪每一个修改过的文件。每当提交操作，Git在目前临时区域的文件。只有文件被认为是目前在临时区域提交，而不是所有修改过的文件。
让我们来看看Git的基本工作流程。
第1步：修改文件的工作目录。
第2步：将这些文件添加到暂存区
第3步：执行commit操作。这将文件从临时区域。推送操作后，它永久地存储更改的Git仓库
假设修改了两个文件，即 “sort.c” and “search.c” ，两种不同分别 提交操作。可以添加一个文件分段区域，不提交。第一次提交后重复相同的步骤为另一个文件。
BLOB代表二进制大对象。为代表 blob文件的每个版本。一个blob保存文件数据，但不包含任何有关文件的元数据。它是一个二进制文件，该文件它被命名为SHA1哈希 Git数据库中。在Git中，文件未提及的名字。一切固定内容寻址。
树是一个对象，它表示一个目录。它拥有blobs以及其他子目录。一棵树是一个二进制文件，该文件存储Blob树，也被命名为树对象的SHA1哈希的引用。
提交持有的库的当前状态。COMMIT命令同样由SHA1哈希的名字命名。可以考虑commit对象的链表节点。每个提交的对象有父commit 对象的指针。从给定的承诺可以遍历寻找在父指针，查看历史记录的提交。如果提交多个父承诺，这意味着特定的提交是由两个分支合并。
分支用来创建另一条线的发展。默认情况下，Git的主分支，这是一样躯干颠覆。平时要工作的新功能创建一个分支。功能完成后，它被合并回master分支，我们删除分支。每个分支所引用HEAD，这点在分支的最新提交。每当做出了一个提交，HEAD更新为最新提交。
包括特定版本库中的标签分配一个有意义的名称。标签是非常相似的分支，但不同的是，标签是不可改变的。手段标记的一个分支，没有人打算修改。一旦标签被创建为特定的提交，即使创建一个新的提交，也不会被更新。通常开发人员创建标签的产品发布。
克隆操作的库创建实例。克隆操作不仅检出的工作拷贝，但它也反映了完整的信息库。用户可以执行许多操作，这个本地仓库。网络介入是唯一的一次，当正在同步资料库实例。
Pull操作复制的变化，本地的一个实例来从远程仓库。Pull操作是用于两个存储库实例之间的同步。这是在Subversion更新操作一样。
推动从本地存储库实例的远程操作副本的变化。这是用来储存到Git仓库中永久改变。这是在Subversion的提交操作相同。
HEAD指针总是指向分支的最新提交。每当你做出了一个提交，HEAD更新为最新提交。HEAD树枝存储在.git/refs/heads/ 目录中。
修订版本的源代码。在Git修订代表的提交。这些提交由SHA1安全哈希值确定。
URL代表的Git仓库的位置。 Git 的URL存储在配置文件中。
在使用Git之前，必须安装它，并做一些基本配置的变化。下面是步骤在Ubuntu和CentOS Linux安装 Git 客户端。
如果使用的是GNU/ Linux 发行版Debian基本apt-get命令就可以搞定一切。
而且，如果使用的是基于RPM的GNU/ Linux发行版使用yum命令，如下：
Git提供git 的配置工具，它允许设置配置变量。 Git会把所有的全局配置.gitconfig 文件位于主目录。要设置这些为全局配置值，添加 -global选项，如果省略 -global选项，那么配置是具体当前的Git存储库。
还可以设置系统范围内的配置。 Git存储这些值是在/etc/gitconfig文件，其中包含的配置系统上的每一个用户和资源库。要设置这些值，必须有root权限，并使用 -system 选项。
上面的代码编译和执行时，它会产生以下结果：
此信息用于Git的每个提交。
此信息用于Git的每个提交。
先从远程资源库的最新变化，如果这些变化是不同的，默认情况下，Git 创建合并提交。我们可以通过以下设置来避免这种。
下面的命令使颜色突出显示在控制台的Git。
默认情况下，Git的使用系统默认取自VISUAL或EDITOR环境变量的编辑器。我们可以设定一个不同的使用git 配置。
Git不会提供一个默认的合并工具整合到工作树冲突的更改。我们可以设置默认的合并工具，通过启用以下设置。
为了验证自己的Git设置本地存储库使用git 的config-list命令，如下所示。
上面的命令会产生以下结果。
在本章中，我们将讨论的Git的生命周期。在后面的章节中，我们将看到的Git命令为每个操作。
一般工作流程是这样的：
- 克隆Git仓库作为工作副本。
- 可以添加/编辑文件，修改工作副本。
- 如果有必要，你还服用其他开发人员的变化，更新工作副本。
- 审查前提交。
- 提交修改。如果一切都很好，然后推到存储库的更改。
- 提交之后，如果知道是什么错误，那么纠正最后一次提交，并推送修改到版本库。
以下是工作流程的图形表示。
在本章中，我们将看到如何创建一个远程Git仓库，从现在开始，我们将会把它作为Git服务器。我们需要一个的Git服务器允许团队协作。
上面的命令会产生以下结果。
让我们初始化一个新的资料库使用init命令后面加上 -bare选项。它初始化没有工作目录库。按照惯例裸库必须命名为 .git。
让我们遍历Git服务器端的配置过程中，使用ssh-keygen实用程序生成公共/私有RSA密钥对，我们将使用这些键进行用户认证。
打开一个终端并输入以下命令，直接按回车为每个输入。成功完成后，它会创建主目录 .ssh目录内。
上面的命令会产生以下结果。
ssh-keygen 已经产生了两个键，第一个是私有的（即id_rsa），另一个是公共（即id_rsa.pub文件）。
> 注: 切勿与他人共享你的私钥。
假设有两个开发项目即Tom 和Jerry工作。两个用户生成公钥。让我们来看看如何使用这些密钥进行身份验证。
Tom 添加他的公钥服务器使用 ssh-copy-id这个命令下面给出
上面的命令会产生以下结果。
同样，Jerry 也增加了他的公共密钥服务器使用 ssh-copy-id 这个命令。
上面的命令会产生以下结果。
我们已经创建了裸库在服务器上，并允许两个用户访问。从现在Tom 和 Jerry 可以把他们修改到版本库，将其添加为远程。
Git的init命令创建 .git 目录来存储元数据的存储库。每次读取配置从 .git/config 文件.
Tom 创建一个新的目录，添加READE文件作为初始提交并提交他的变化。提交后，他确认提交信息，运行git日志命令。
上面的命令会产生以下结果。
Tom 执行git 的日志命令，检查日志消息。
上面的命令会产生以下结果。
Tom 提交了他的变化到本地资源库。现在是时候将更改到远程仓库。但在此之前，我们必须添加作为远程仓库，这是一个时间的操作。在此之后，他可以放心地推送到远程存储库的更改。
> 注: 默认情况下，Git的推到匹配的分支：对于每一个分支退出本地端的远程端更新，如果已经存在具有相同名称的一个分支。在我们的教程每次我推原点主分支的变化，根据您的要求，使用适当的分支名。
上面的命令会产生以下结果。
现在更改成功提交到远程仓库。
我们有一个裸库Git服务器，Tom 也推了他的第一个版本。现在，Jerry 可以查看他的变化。克隆操作的远程存储库创建实例。
Jerry 在他的home目录，并创建新的目录，执行克隆操作。
上面的命令会产生以下结果。
Jerry 改变目录到新的本地存储库，并列出目录内容。
Jerry 克隆库，他决定实现基本字符串操作。于是，他创建文件string.c，在添加内容到 string.c 会这个样子。
他编译和测试代码，一切工作正常。现在，他可以放心地添加这些修改到版本库。
Git 添加操作添加文件到暂存区。
Git是显示文件名前的问号。显然，这些文件不属于Git，Git 不知道该怎么用这些文件。这就是为什么Git是文件名前显示问号。
Jerry 添加文件到存储区域，git的状态命令将显示文件暂存区域。
要提交更改他用git 的commit 命令-m选项。如果我们省略-m选项git会打开文本编辑器，在这里我们可以写多行提交信息。
上面的命令会产生以下结果。
提交后查看日志信息，他使用 git 日志命令。它会显示提交ID所有提交的信息，提交作者，提交日期和提交的 SHA-1散列。
上面的命令会产生以下结果。
但查看提交详细资料后，Jerry 实现字符串的长度不能为负数，所以他决定改变my_strlen函数的返回类型。
Jerry 使用git日志命令来查看日志信息。
上面的命令会产生以下结果。
Jerry 使用git show命令查看提交的细节。 Git的show命令的SHA-1提交ID作为参数。
上面的命令会产生以下结果。
他改变了函数的返回类型 从int 修改为 size_t。测试代码后，他查看其变化运行git diff命令。
上面的命令会产生以下结果。
Git 的差异显示+号前行，这是新增加的，并显示符号被删除。
Jerry 已经提交的更改，他想纠正他的最后一次提交，在这种情况下，git 的修改将帮助操作。最后提交修改操作的变化，包括提交信息，它创建新的提交ID。
修改操作之前，他会检查提交日志。
上面的命令会产生以下结果。
Jerry 提交了新的变化 - 修改操作，并查看提交日志。
现在 git 的日志，将显示新的提交信息与新的提交ID
上面的命令会产生以下结果。
Jerry 修改了他的最后一次提交的修改操作，他已经准备好将更改。推操作的数据永久存储的 Git 仓库。推操作成功后，其他开发人员可以看到Jerry 的变化。
他执行的git日志命令来查看提交的细节。
上面的命令会产生以下结果。
push操作之前，他要审查他的变化，所以使用git show命令来查看他的变化。
上面的命令会产生以下结果。
Jerry 为他的变化感到高兴，他是准备推他的变化。
上面的命令会产生以下结果。
Jerry 的变化成功地推到版本库，现在其他开发人员可以查看他的变化进行克隆或更新操作。
Tom 执行克隆操作后，看到新的文件string.c，他想知道这个文件到存储库？目的是什么？于是，他执行 git 日志命令。
上面的命令会产生以下结果。
克隆操作将当前的工作目录内创建新的目录。他改变目录到新创建的目录和执行 git日志命令。
上面的命令会产生以下结果。
查看记录后，他意识到，string.c 文件加入Jerry 实现基本字符串操作。他是好奇Jerry 的代码。于是他打开文本编辑string.c 文件，并立即找到了一个漏洞。 my_strlen函数中 Jerry 没有使用常量指针。于是，他决定修改Jerry 的代码。修改后的代码会这个样子。
上面的命令会产生以下结果。
经过测试，他提交他的变化。
上面的命令会产生以下结果。
Tom 使用git push命令，推他的变化。
上面的命令会产生以下结果。
与此同时，Jerry 决定实现字符串比较函数。于是，他修改string.c文件。修改后的文件会这个样子。
上面的命令会产生以下结果。
经过测试，他准备推他的变化。
push操作之前，他验证通过查看日志信息提交。
上面的命令会产生以下结果。
Jerry 为变化感到高兴，他想推他的变化
上面的命令会产生以下结果。
但是，Git 是不允许Jerry 推他的变化。因为Git确定该远程仓库和Jerry 的本地资源库不同步。正因为如此，他可能会失去项目的历史。因此，为了避免这种混乱的Git 对此操作失败。Jerry 必须首先更新它的本地存储库，然后再只有他才能把他自己的变化。
Jerry 执行git pull命令远程命令来同步自己的本地仓库。
上面的命令会产生以下结果。
抽取操作后Jerry 检查日志消息，并找到 Tom 的提交详细，提交ID为 cea2c000f53ba99508c5959e3e12fff493ba6f69
上面的命令会产生以下结果。
现在，Jerry 的本地存储库是完全同步的远程仓库。所以，他可以放心地将他的变化。
上面的命令会产生以下结果。
假设您正在为您的产品实施的一项新功能。你的代码是在推进开发进度而客户不断升级需求突然来了。正因为如此，你必须保持放下你的新功能，工作几个小时。你不能提交你的部分代码，也不能扔掉你的变化。所以，你需要一些临时空间，在那里你可以存储你的部分修改，以便以后再提交。
在Git中，藏匿操作需要修改的跟踪文件和阶段的变化，并将其保存在栈上未完成的更改，可以在任何时候重新。
现在要切换分支机构为客户不断升级，但你不想提交你的工作，所以你会藏匿的变化。要推一个新的藏匿到您的堆栈，运行git stash命令
现在你的工作目录是干净的，所有的改变都保存在堆栈。让我们用git status命令验证。
现在可以安全地切换分支和做其他工作。我们可以看到的藏匿的变化列表通过使用 git stash list 命令。
假设你解决了客户不断升级和你要回到你的工作，已经做了一半的代码。只要执行git stash pop 命令，它会从堆栈中删除的变化，并把它放在当前工作目录。
上面的命令会产生以下结果。
顾名思义移动(move )操作移动目录或文件从一个位置到另一个。Tom 决定移动到src目录下的源代码。因此，修改后的目录结构看起来会像这样。
要进行这些永久性更改，以便其他开发人员可以看到这一点，我们必须修改的目录结构推到远程存储库。
在Jerry 的本地资源库，抽取操作前，它会显示旧的目录结构。
但是，抽取(pull )操作后的目录结构将得到更新。现在，Jerry 可以看到该目录内的 src目录和文件。
截至目前，Tome 和Jerry 都使用手动命令来编译自己的项目。Jerry 决定为他们的项目创建 Makefile，并给予适当的名称来命名“string.c” 文件。
Git 是显示R在文件之前名称来指示文件已更名。
对于提交操作Jerry 使用 -a标志，这使得git 提交自动检测修改过的文件。
提交后，他推送了他的修改到版本库。
上面的命令会产生以下结果。
现在，其他开发人员可以通过更新他们的本地资源库中的这些修改。
Tom 更新了自己的本地存储库并进入src目录下找到编译后的二进制。查看提交信息后，他意识到，编译后的二进制是由Jerry加入的。 .
VCS用于存储源代码，而不是只对可执行的二进制文件。因此，Tom 决定从资源库中删除此文件。对于进一步的操作，他使用git 的 rm命令。
提交后，他推送了他的修改到版本库。
上面的命令会产生以下结果。
大部分的人都会犯错。所以每VCS提供了一个功能，修正错误，直到特定的点。 Git提供功能使用，我们可以撤销已作出的修改到本地资源库。
假设用户不小心做了一些更改，以他的本地的仓库，现在他要扔掉这些变化。在这种情况下，恢复操作中起着重要的作用。
让我们假设Jerry 不小心修改文件从自己的本地仓库。但他想扔掉他的修改。要处理这种情况，我们可以使用git checkout命令。我们可以使用这个命令来恢复文件的内容。
甚至我们可以使用git checkout命令删除的文件从本地库。让我们假设Tom 删除文件从本地存储库，我们希望这个文件。我们可以做到这一点，使用相同的命令。
Git是显示文件名前的字母D。这标志着该文件已被删除，从本地资源库。
> 注意：我们可以执行所有这些操作之前提交操作。
我们已经看到，当我们执行加法运算;文件移动从本地存储库，参数区域。如果用户不小心修改一个文件，并把它添加到临时区域，但他马上意识到犯了错误。他希望恢复他的改变。我们可以处理这种情况下，通过使用git checkout命令。
在Git是一个HEAD指针始终指向最新提交。如果想撤销变更分阶段区域，那么可以使用git checkout命令，但checkout命令，必须提供额外的参数HEAD指针。额外提交指针参数指示的git checkout命令，重置工作树，还能够去除分阶段。
让我们假设Tom 从自己的本地仓库修改一个文件。如果我们查看这个文件的状态，它会显示文件被修改，但不加入临时区域。
Git 的状态显示该文件是在分期区域，现在它恢复使用git checkout命令和视图状态恢复的文件。
做一些改变后，可能会决定删除这些更改。 Git 复位命令是用来重置或恢复一些变化。我们可以执行三种不同类型的复位操作。
下图显示图形表示 Git复位命令。
每个分支都有HEAD 指针指向最新提交。如果我们使用git --soft复位命令选项，随后提交ID，然后将只有头指针复位，不破坏任何东西。
.git/refs/heads/master 文件存储的提交ID 的HEAD 指针。我们可以验证它通过使用git log -1 命令。
现在查看最新提交的ID，这将配合上述提交ID。
上面的命令会产生以下结果。
让我们重设HEAD 指针。
现在我们只重设HEAD 指针回到一个位置。让我们检查内容.git/refs/heads/master 文件.
从文件提交ID改变，现在验证通过查看提交的信息。
上面的命令会产生以下结果。
Git的复位 -- mixed选项从分段区域尚未提交还原更改。它仅恢复变化形成暂存区。实际所做的更改到工作副本的文件不受影响。默认的Git的复位相当于git的复位 -- mixed。
有关更多详细信息，请参阅部分删除同一章临时区域变化。
如果使用 - hard选项用 Git复位命令，它会清除暂存区域，它会重设HEAD 指针，以最后一次提交的具体提交ID，也删除本地文件的变化。
让我们检查提交的ID
上面的命令会产生以下结果。
Jerry 修改过的文件，在文件的开始，加入单行注释。
他使用git status命令验证。
Jerry 修改后的文件添加到分期区域，并验证它与git的状态运行。
上面的命令会产生以下结果。
Git的状态，显示该文件是在临时区域。现在重置HEAD 用 --hard选项。
Git 复位命令成功，这将恢复从分段区的文件，以及删除本地对文件所做的更改。
Git 状态显示，文件恢复从分段区。
Head 命令还显示，复位操作删除局部变化。
允许有意义的名称到一个特定的版本库中的标签操作。Tom 决定标记他们的项目代码，以便他们以后可以更容易访问。
让我们标记当前HEAD使用git tag命令。他提供的标记名称前加上-a选项，使用-m选项，并提供标签信息。
如果想标记特定提交然后使用适当的COMMIT ID，而不是HEAD 指针。 Tom使用下面的命令推到远程存储库中的标签。
上面的命令会产生以下结果。
Tom 创建标签。现在，Jerry 可以查看所有可用标签通过使用Git tag命令使用-l选项。
Jerry 使用Git的show命令后跟标记名称的有关标签查看更多细节。
上面的命令会产生以下结果。
Tom使用下面的命令来删除标记从本地以及远程仓库。
补丁是文本文件，其内容是相似于Git diff，但随着代码，它也有元数据有关提交，如提交ID，日期，提交信息等，我们可以创建补丁提交和其他人可以将它们应用到自己的资料库。
Jerry 为他们的项目实现strcat函数。 Jerry 可以创建自己的代码路径发送到Tom。那么他就可以收到Jerry 的代码补丁。
杰里使用Git format-patch 命令来创建最新提交的补丁。如果想创建补丁具体提交，然后使用COMMIT_ID 和 ormat-patch 命令。
上面的命令创建 .patch文件里在当前工作目录。 Tom可以使用这个补丁修改他的文件。 Git提供两个命令来应用补丁调幅分别为： git am 和 git apply . Git apply命令修改本地文件时，而无需创建提交，git am命令修改文件，会一并创建提交。
适用于修补程序并创建提交使用下面的命令。
补丁得到成功应用，现在我们可以使用git diff命令查看修改。
上面的命令会产生以下结果。
分支操作可以创造另一条线的发展。对fork过程分为两个不同的方向发展，我们可以使用此操作。例如，我们发布了6.0版本的产品，我们可能要创建一个分支，使7.0功能的发展可以保持独立从6.0 bug修复。
使用Git分支<branch name> 命令创建新的分支。从现有的，我们可以创建一个新的分支。我们可以使用特定的提交或标签作为一个起点。如果没有提供任何具体的提交ID，然后分支将HEAD 创建作为一个起点。
创建新的分支，Tom用 git branch命令列出可用的分支。 Git会显示星号标记之前，当前检出的分支。
下面是创建分支操作的图形表示
Jerry 使用git checkout命令到分支之间切换。
在上面的例子中，我们使用了两个命令来创建和切换分支。 Git提供checkout命令 -b选项，此操作将创建新的分支，并立即切换到新的分支。
一个分支可以用git branch命令的-D选项被删除。但在此之前，删除现有的分支切换到其他分支。
Jerry 当前在test_branch 想要删除该分支。于是，他分支和删除分支切换，如下图所示。
现在Git会显示只有两个分支。
Jerry 决定添加宽字符支持他的字符串操作项目。他已经创建了一个新的分支，但分支名称是不恰当的。于是，他通过使用-m选项，其次是旧分支名称和新分支名称变更分支名称。
现在git branch命令将显示新分支名称。
Jerry 实现函数返回字符串的长度为宽字符串。新代码将看起来像这样
上面的命令会产生以下结果。
测试后，他提交他的变化，并推到新的分支。
注意杰里推动这些变化的新分支，这就是为什么他用wchar_support分支的名称，而不是master分支。
上面的命令会产生以下结果。
经过分支提交的变化，新分支会这个样子。
Tom 好奇Jerry 在做什么在他的私人分支，这就是为什么他检查日志从wchar_support 分支。
上面的命令会产生以下结果。
通过查看提交的信息，Tom 意识到Jerry 实现宽字符strlen 函数，他希望同样的功能集成到主分支。而不是重新实现他的分支合并到主分支，他决定采用杰里的代码。
合并操作后的主分支会这个样子。
现在wchar_support分支合并到主分支中我们可以验证它的查看提交信息，通过查看修改成string_operation.c文件。
上面的命令会产生以下结果。
经过测试，他把他的代码更改到主分支。
Git 的 rebase命令的一个分支合并的命令，但不同的是，它修改提交的顺序。
Git merge命令，试图把从其他分支提交当前的本地分支的HEAD上。例如 本地的分支已经提交A-> B-> C-> D和合并分支已提交A-> B-> X> Y，则Git合并将当前转换像这样的本地分行A-> B-> C-> D-> X-> Y
Git 的rebase命令试图找到当前的本地分支和合并分支之间的共同祖先。然后把修改提交的顺序，在当前的本地分支提交中的本地分支。例如，如果当地的分支已提交A-> B-> C-> D和合并分支已提交A-> B-> X-> Y，Git衍合的类似A-> B转换成当前的本地分支A−>B−>X−>Y−>C−>D
当多个开发人员在一个单一的远程资源库的工作，你不能在远程仓库提交修改订单。在这种情况下，可以使用变基操作把本地提交的远程仓库之上的提交，可以推送这些变化。
Jerry 工作在wchar_support分支。他改变了名称的功能和测试后，他提交他的变化。
上面的命令产生以下结果
验证代码后，他提交了他的变化。
上面的命令会产生以下结果。
同时在主分支Tom 也改变了名称相同的功能，并将其更改到主分支。
上面的命令会产生以下结果。
验证差异后，他提交了他的变化。
上面的命令会产生以下结果。
strchr 函数在分支Jerry 实现 wchar_support宽字符字符串。经过测试，他提交和推送其变化 wchar_support 分支。
上面的命令会产生以下结果。
验证变化后，他提交他的变化。
上面的命令会产生以下结果。
Tom想看，Jerry 在他的私人分支做什么？这就是为什么他试图从wchar_support分支把最新的修改，但Git 放弃操作在得到错误消息后。
上面的命令会产生以下结果。
从错误消息很显然知道，是有冲突的在src/string_operations.c。他运行 git diff 命令查看进一步的细节。
上面的命令会产生以下结果。
由于Tom 和Jerry 在相同的功能更改的名称，Git不知道如何去做，因此这就是为什么它要求用户手动解决冲突。
Tom 决定保用 Jerry 建议的函数名，但他使用原来注释，因为这是他加入的。删除冲突标记混帐后差异会看起来像这样。
上面的命令会产生以下结果。
Tom 修改过的文件，他先提交这些更改后，他就可以推送了。
Tom 已经解决冲突，现在推送操作将成功。
GNU/ Linux 和 Mac OS使用换行符（LF）或新行作为行结束字符，而Windows 使用换行和回车（LFCR）的组合来表示行结束字符。
为了避免不必要的提交，因为这些行结束的差异，Git客户端配置写在同一行结束 Git 仓库。
对于Windows系统中，我们可以配置的Git客户端换行符转换为CRLF格式，同时检查了，并把它们转换回LF格式提交操作过程中。下面设置将不可少。
对于GNU/ Linux或Mac OS，我们可以配置 Git 客户端CRLF 到 LF换行符转换，同时进行检出（checkout ）操作。
GitHub是使用Git的版本控制系统是一个基于网络的托管服务的软件开发项目。它也有其标准的GUI应用程序可供下载（在Windows，Mac，GNU/Linux）的直接从服务的网站。但在这个环节中，我们将只能看到CLI部分。
去到 github.com. 如果您已经GitHub的帐户，然后使用该帐户登录，或创建新的。从 github.com 网站按照以下步骤来创建新的存储库。
Tom 决定使用GitHub上服务器。要开始新的项目，他将创建一个新的目录和一个文件里面。
上面的命令会产生以下结果。
在验证自己的代码后，他在初始化目录用git init命令在本地提交他的变化。
之后，他增加了GitHub的版本库URL作为一个远程的起源，并推他到远程仓库。
> 注：我们已经讨论了所有这些步骤在第4章下创建裸库部分。
推送操作会询问 GitHub 的用户名和密码。验证成功后，操作会成功。
上面的命令会产生以下结果。
从现在开始，Tom 可以在 GitHub 库做任何更改。他可以使用本章讨论的所有命令在 GitHub 的仓库中。
Tom 成功地把他所有的变化GitHub的库。现在其他开发人员可以查看这些更改进行克隆操作或更新他们的本地资源库。
Jerry 在他的home目录和克隆的GitHub库使用git clone命令创建新的目录。
上面的命令会产生以下结果。
他验证通过执行ls命令的目录内容。
Git是目前最流行的版本管理系统，学会Git几乎成了开发者的必备技能。
Git有很多优势，其中之一就是远程操作非常简便。本文详细介绍5个Git命令，它们的概念和用法，理解了这些内容，你就会完全掌握Git远程操作。
- git clone
- git remote
- git fetch
- git pull
- git push
本文针对初级用户，从最简单的讲起，但是需要读者对Git的基本用法有所了解。同时，本文覆盖了上面5个命令的几乎所有的常用用法，所以对于熟练用户也有参考价值。
版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/do-yfwjc/23499.html