Git使用教程 - 完整入门指南（2024）

手机扫码，畅享阅读

目�����录 前言 Git�基本概念 Git�环境设置（安装） Git�生命周期 Git�创建操作 Git�克隆操作 Git�执行更改 Git�审查更改 Git�提交更改 Git�推送操作 Git�更新操作 Git�藏匿操作 Git�移动操作 Git�重命名操作 Git�删除操作 Git�修正错误 Git�标签操作 Git�补丁操作 Git�管理分支 Git�冲突处理 Git�不同的平台 GitHub�在线存储库 Git远程操作详解 git�clone git�remote git�fetch git�pull git�push -�2�- 本文档使用�看云�构建 前言 Git�教程 Git�是一个分布式的版本控制和源代码管理系统，强调速度。�Git�最初由Linus�Torvalds设计 和开发为Linux内核开发管理代码。�Git是GNU通用公共许可证版本2的条款下分发的免费软 件。 本教程将教你如何使用Git�在你的项目版本控制在分布式环境中的基于�Web�和非基于Web 应用程序的开发工作。 读者 对于初学者来说已经准备本教程，帮助他们了解Git版本控制系统的基本功能。完成本教程 后，可以把帮助你熟悉和使用Git版本控制系统。 前提条件 我们假设你要使用�Git�来处理各级�Java�和非Java项目。所以如果你有知识，开发的基于 Web�和非基于�Web�的应用程序的软件开发生命周期和知识，将有助于学习和使用Git。 前言 -�3�- 本文档使用�看云�构建 Git�基本概念 版本控制系统�(VCS) 版本控制系统�(VCS)�是软件，帮助软件开发人员携手合作，他们的工作并保持完整的历史。 以下是VCS目标 1.� 允许开发人员同步工作. 2.� 不要覆盖对方的变化. 3.� 维护历史的每一个版本. 以下是常见的VCS 1.� 集中式版本控制系统（CVCS） 2.� 分散式/分布式版本控制系统（DVCS） 在这个教程，我们将介绍集中分布式的版本控制系统，尤其是Git。�Git�属于分布式版本控制 系统。 分布式版本控制系统（DVCS） 集中式版本控制系统采用中央服务器上存储的所有文件和实现团队协作。但是CVCS主要 缺点是中央服务器的单点故障，即故障。不幸的是，如果中央服务器宕机一小时，然后在该 时段没有人可以合作。即使在最坏的情况下，如果中央服务器的磁盘被损坏，并没有采取适 当的备份，那么将失去整个项目的历史。 DVCS客户不仅检出的最新快照目录，但他们也完全反映资源库。如果SEVER停机，然 后从任何客户端库可以复制回服务器，以恢复它。每个结账是完整的版本库备份。�Git不会 依赖中央服务器，这就是为什么可以执行许多操作，当处于脱机状态。可以提交修改，创建 分支视图日志和执行其他操作，当处于脱机状态。只需要网络连接，发布您的更改，并采用 最新变化。 Git优势 Git是GPL开源许可证下发布的。它可自由在互联网上。可以使用Git来管理项目无需支 付一分钱。由于它是开源的，可以下载它的源代码，并根据要求进行更改。 由于大部分的操作都在本地执行，它给人带来巨大的好处，在速度方面。�Git�不依赖于 中央服务器，为什么每一个操作就没有必要与远程服务器进行交互。�Git核心部分是写在C Git�基本概念 -�4�- 本文档使用�看云�构建 中，从而避免了与其他高级语言的运行时开销。虽然�Git中反映整个存储库，在客户端上的 数据的大小是小的。这说明它是在客户端上的数据压缩和存储的效率有多高。 丢失数据的机会是非常罕见的，当有多个副本。存在于任何客户端的数据存储库中，因 此它可以被用来在发生崩溃或磁盘损坏的镜像。 Git使用常见的加密散列函数，称为安全的哈希算法（SHA1）命名，并确定在其数据库 中的对象。每一个文件并提交检查总结和检索其校验在结账的时候。意思是说，这是不可能 改变文件，日期，提交信息和且从Git�数据库不知道Git�任何其他数据。 在CVCS情况下，中心服务器需要足够强大，要求整个团队服务。对于较小的团队，这是 不是一个问题，但随着团队规模的增长，服务器的硬件限制可能成为一个性能瓶颈。在 DVCS开发的情况下不与服务器进行交互，除非他们需要推或拉的变化。所有繁重发生在客 户端上，所以服务器硬件可以是很简单的。 CVCS使用廉价的复制机制，这意味着如果我们创建新的分支，它会复制到新分支的所有 代码，所以它的耗时和效率不高。另外CVCS的分支的删除和合并是复杂和费时的。但是，使 用Git分支管理是很简单的。只需要几秒钟，创建，删除和合并分支。 1.� 自由和开放源码 2.� 快速和小 3.� 隐式备份 4.� 安全 5.� 不需要强大的硬件 6.� 更简单的分支 DVCS术语 本地资源库 每个VCS工具提供私有工作场所的工作副本。开发者在他的私人工作场所的变化，并提 交这些更改后成为仓库的一部分。�Git的需要这一步，为他们提供的专用副本是整个仓库。 用户可以执行许多操作，这个库中，如添加文件，删除文件，重命名文件，移动文件，提交 改变，还有更多。 工作目录，暂存区域或索引 工作目录是地方文件检出。其他CVCS开发商一般不修改，并承诺他的变化，直接向版本 库。但Git使用不同的策略。�Git不会跟踪每一个修改过的文件。每当提交操作，Git在目前临 时区域的文件。只有文件被认为是目前在临时区域提交，而不是所有修改过的文件。 Git�基本概念 -�5�- 本文档使用�看云�构建 让我们来看看Git的基本工作流程。 第1步：修改文件的工作目录。 第2步：将这些文件添加到暂存区 第3步：执行commit操作。这将文件从临时区域。推送操作后，它永久地存储更改的Git仓库  假设修改了两个文件，即�“sort.c”�and�“search.c”�，两种不同分别�提交操作。可 以添加一个文件分段区域，不提交。第一次提交后重复相同的步骤为另一个文件。 #�First�commit [bash]$�git�add�sort.c #�adds�file�to�the�staging�area [bash]$�git�commit�–m�“Added�sort�operation” <br/> #�Second�commit [bash]$�git�add�search.c #�adds�file�to�the�staging�area [bash]$�git�commit�–m�“Added�search�operation” BLOBS BLOB代表二进制大对象。为代表�blob文件的每个版本。一个blob保存文件数据，但不 包含任何有关文件的元数据。它是一个二进制文件，该文件它被命名为SHA1哈希�Git数据库 中。在Git中，文件未提及的名字。一切固定内容寻址。 Tree 树是一个对象，它表示一个目录。它拥有blobs以及其他子目录。一棵树是一个二进制 文件，该文件存储Blob树，也被命名为树对象的SHA1哈希的引用。 Commit 提交持有的库的当前状态。COMMIT命令同样由SHA1哈希的名字命名。可以考虑 commit对象的链表节点。每个提交的对象有父commit�对象的指针。从给定的承诺可以遍历 寻找在父指针，查看历史记录的提交。如果提交多个父承诺，这意味着特定的提交是由两个 分支合并。 Git�基本概念 -�6�- 本文档使用�看云�构建 BRANCHES 分支用来创建另一条线的发展。默认情况下，Git的主分支，这是一样躯干颠覆。平时要 工作的新功能创建一个分支。功能完成后，它被合并回master分支，我们删除分支。每个分 支所引用HEAD，这点在分支的最新提交。每当做出了一个提交，HEAD更新为最新提交。 TAGS 包括特定版本库中的标签分配一个有意义的名称。标签是非常相似的分支，但不同的 是，标签是不可改变的。手段标记的一个分支，没有人打算修改。一旦标签被创建为特定的 提交，即使创建一个新的提交，也不会被更新。通常开发人员创建标签的产品发布。 CLONE 克隆操作的库创建实例。克隆操作不仅检出的工作拷贝，但它也反映了完整的信息库。 用户可以执行许多操作，这个本地仓库。网络介入是唯一的一次，当正在同步资料库实例。 PULL Pull操作复制的变化，本地的一个实例来从远程仓库。Pull操作是用于两个存储库实例之 间的同步。这是在Subversion更新操作一样。 PUSH 推动从本地存储库实例的远程操作副本的变化。这是用来储存到Git仓库中永久改变。这 是在Subversion的提交操作相同。 HEAD HEAD指针总是指向分支的最新提交。每当你做出了一个提交，HEAD更新为最新提交。 HEAD树枝存储在.git/refs/heads/�目录中。 [CentOS]$�ls�-1�.git/refs/heads/ master [CentOS]$�cat�.git/refs/heads/master 570837e7d58fa4bccd86cb575d884502188b0c49 REVISION 修订版本的源代码。在Git修订代表的提交。这些提交由SHA1安全哈希值确定。 URL URL代表的Git仓库的位置。�Git�的URL存储在配置文件中。 [tom@CentOS�tom_repo]$�pwd /home/tom/tom_repo Git�基本概念 -�7�- 本文档使用�看云�构建 [tom@CentOS�tom_repo]$�cat�.git/config [core] repositoryformatversion�=�0 filemode�=�true bare�=�false logallrefupdates�=�true [remote�"origin"] url�=�gituser@git.server.com:project.git fetch�=�+refs/heads/*:refs/remotes/origin/* Git�基本概念 -�8�- 本文档使用�看云�构建 Git�环境设置（安装） 在使用Git之前，必须安装它，并做一些基本配置的变化。下面是步骤在Ubuntu和CentOS Linux安装�Git�客户端。 Git客户端安装 如果使用的是GNU/�Linux�发行版Debian基本apt-get命令就可以搞定一切。 [ubuntu�~]$�sudo�apt-get�install�git-core [sudo]�password�for�ubuntu: [ubuntu�~]$�git�--version git�version�1.8.1.2 而且，如果使用的是基于RPM的GNU/�Linux发行版使用yum命令，如下： [CentOS�~]$ su�- Password: [CentOS�~]#�yum�-y�install�git-core [CentOS�~]#�git�--version git�version�1.7.1 自定义Git环境 Git提供git�的配置工具，它允许设置配置变量。�Git会把所有的全局配置.gitconfig�文件 位于主目录。要设置这些为全局配置值，添加�-global选项，如果省略�-global选项，那么配 置是具体当前的Git存储库。 还可以设置系统范围内的配置。�Git存储这些值是在/etc/gitconfig文件，其中包含的配 置系统上的每一个用户和资源库。要设置这些值，必须有root权限，并使用�-system�选项。 设置用户名 此信息用于Git的每个提交。 [byron@CentOS�project]$�git�config�--global�user.name�"byron" Git�环境设置（安装） -�9�- 本文档使用�看云�构建 设置电子邮件ID 此信息用于Git的每个提交。 [byron@CentOS�project]$�git�config�--global�user.email�"xiaobosun@gridinf o.com.cn" 避免PULLING提交合并 先从远程资源库的最新变化，如果这些变化是不同的，默认情况下，Git�创建合并提交。我 们可以通过以下设置来避免这种。 byron@CentOS�project]$�git�config�--global�branch.autosetuprebase�always 颜色高亮 下面的命令使颜色突出显示在控制台的Git。 [byron@CentOS�project]$�git�config�--global�color.ui�true [byron@CentOS�project]$�git�config�--global�color.status�auto [byron@CentOS�project]$�git�config�--global�color.branch�auto 设置默认编辑器 默认情况下，Git的使用系统默认取自VISUAL或EDITOR环境变量的编辑器。我们可以设定一 个不同的使用git�配置。 [byron@CentOS�project]$�git�config�--global�core.editor�vim 设置默认的合并工具 Git不会提供一个默认的合并工具整合到工作树冲突的更改。我们可以设置默认的合并工具， 通过启用以下设置。 [byron@CentOS�project]$�git�config�--global�merge.tool�vimdiff 列出GIT设置 为了验证自己的Git设置本地存储库使用git�的config-list命令，如下所示。 [byron@CentOS�~]$�git�config�--list Git�环境设置（安装） -�10�- 本文档使用�看云�构建 上面的命令会产生以下结果。 user.name=Byron user.email=xiaobosun@gridinfo.com.cn push.default=nothing branch.autosetuprebase=always color.ui=true color.status=auto color.branch=auto core.editor=vim merge.tool=vimdiff Git�环境设置（安装） -�11�- 本文档使用�看云�构建 Git�生命周期 在本章中，我们将讨论的Git的生命周期。在后面的章节中，我们将看到的Git命令为每个操 作。 一般工作流程是这样的： 1.� 克隆Git仓库作为工作副本。 2.� 可以添加/编辑文件，修改工作副本。 3.� 如果有必要，你还服用其他开发人员的变化，更新工作副本。 4.� 审查前提交。 5.� 提交修改。如果一切都很好，然后推到存储库的更改。 6.� 提交之后，如果知道是什么错误，那么纠正最后一次提交，并推送修改到版本库。 以下是工作流程的图形表示。  Git�生命周期 -�12�- 本文档使用�看云�构建