软件基础技术构建 2

开源软件构建技术——开源软件版本控制管理《开源软件构建技术：理论与实践》2课件使用介绍课程资源网站(正在建设中，持续更新维护)：课程配套8个实践案例：/paths/krytlieb

部署在头歌平台，

关卡作答模式，平台配套实验环境。欢迎老师在头歌平台新建课堂，引入课程实验案例资源。3.课程部分互动，学生作答环节(投票题)，需要下载安装“雨课堂”应用。

开源软件版本控制管理：

章节目录30102Git数据模型03Git概述Git设计原理7版本控制的概念版本控制的历史Git的设计目标02Git存储模型Git分支机制使用前准备Git基本操作04Git工作流程CloneFork03目录结构三大工作区Commit、Pull、PushGit工作原理开放式协作1

Git概述：版本控制的概念4你可能有以下类似的经历，假设如下场景：你和小组成员共同完成一份点餐系统的代码，你完成登录功能后把第一份代码打包命名为restaurant_v1.zip小组成员A完成了用户管理功能，打包为restaurant_v2.zip小组成员B完成了餐品管理功能，打包为restaurant_v3.zip小组成员D在C的基础上对整个项目进行调整合并，并进行测试，命名为restaurant_v5.zipB和C发现了自己功能存在问题，将相关代码发送给D，D直接在最新版本的代码上进行了手动修改最终发现系统运行失败，但已经无法追溯是哪一次修改引入了问题小组成员C完成了点餐功能，打包为restaurant_v4.zip1

Git概述：版本控制的概念5缺少版本管理可能导致灾难：没有版本控制系统的协作开发，困难重重！不小心误删了某个版本的代码，但已经没有相关备份追溯困难小组成员共同完成这份代码。但每一次都需要合并代码，工作量同样非常庞大。协作低效小组成员可能在没有保存前一次修改，直接做了新的修改，旧的修改被覆盖，再也找不到原始记录。修改覆盖最终版本无法运行，但不确定是谁的修改引入了错误，最后一次可以运行的版本到底哪一个。版本混乱什么是版本控制61

Git概述：版本控制的概念7“版本控制系统(VersionControlSystem,VCS)”是自动执行代码版本控制管理过程的软件，便于开发者撤回到项目较早的版本，支持项目成员互不干扰地协作开发项目。发布代码版本v1新的特性版本v2Bug修复版本v3软件代码发布后，随着软件的发展，开发人员不断开发新的特性、修复各种Bug，源代码随时间推移不断产生变更。

“版本控制(VersionControlSystem,VC)”就是跟踪与管理源代码的每一次变更。持续更新…1

Git概述：最广泛使用的版本控制系统8使用Git的平台Git的介绍1

Git概述：基于Git的代码托管平台9GitHub1

Git概述：基于Git的代码托管平台10Gitee1

Git概述：基于Git的代码托管平台11Gitlab没有Git之前如何进行版本管理121

Git概述：版本控制系统的前世今生13最早的时候，开发者通过原始的文件副本管理方式(如手工备份、日期后缀命名)来维系代码版本。这种粗放的管理方式使得开发者难以回溯到特定版本，最新的修改可能覆盖原本尚能运作的版本，从而导致了版本管理的混乱。手工管理代码代码V1代码v2代码最终版代码完成版……1

Git概述：版本控制系统的前世今生14本地版本管理早期版本控制工具如SCCS、RCS实现了文件的差异存储算法，版本库位于本地磁盘，可以在本地进行单机的版本控制管理。然而这些工具无法协同开发,同一时间只能有一个开发者处理文件。SCCS(SourceCodeControlSystem)，是最早的版本控制系统，诞生于1972年，实现了对单个文件保留多个版本，为开发者提供了基本版本追踪功能，允许回退到历史版本并查看代码变更记录。RCS(RevisionControlSystem)，则诞生于1982年，它通过保存文件的补丁集来实现版本管理，通过叠加补丁可以恢复到任意历史版本。1

Git概述：版本控制系统的前世今生15为了支持多人协作开发，出现了集中式版本控制系统(CentralizedVersionControlSystems，CVCS)。CVCS采用单一的集中式服务器来管理代码的变更历史，所有的代码以及版本历史存放在中央服务器，开发者通过客户端从服务器获取代码或提交变更。集中式版本管理ComputerAFileComputerBCentralVCSServerFileVersionDatabaseVersion3Version2Version1CVS(ConcurrentVersionsSystem)是最早的集中式版本控制系统，SVN(Subversion)则是集中式版本控制系统的集大成者。1

Git概述：版本控制系统的前世今生16CVS诞生于1985年，由荷兰阿姆斯特丹自由大学的DickGrune教授开发。CVS通过RCS的格式保存项目文件，版本库保存各文件的最新完整版本和反向差异(delta)链，开发者通过Checkout将项目从中央服务器的CVS版本库复制到本地，在本地修改副本，完成后将修改提交至中央版本库中。集中式版本管理1

Git概述：版本控制系统的前世今生17SVN由CollabNet公司在2000年资助开发，目的是对CVS的改进并取代CVS。相比于CVS，SVN主要有以下优势：集中式版本管理01原子提交SVN支持原子提交，即每次提交所有文件作为一个整体进行提交，要么全部成功，要么全部失败，确保版本库的一致性。而CVS在提交过程中可能由于传输中断出现数据库不完整以及数据损坏等。03二进制差异存储算法SVN将二进制文件与非二进制文件都以压缩的方式存储在版本库中，节省了存储空间。02目录版本控制CVS只能支持对单个文件的历史版本进行追踪，而SVN还支持对目录的版本控制，对文件和目录的创建、删除、复制和重命名等操作都会被记录和追踪。04轻量级分支和标签SVN通过拷贝的方式创建和管理分支、标签，这种操作开销较小。1

Git概述：版本控制系统的前世今生18集中式版本管理单点式故障依赖网络效率低下中央仓库开发者开发者开发者相比于早期，SVN已经是非常优秀的版本管理工具，然而仍有难以接受的局限性！1

Git概述：版本控制系统的前世今生19分布式版本管理集中式版本控制系统的缺陷令Linux之父LinusTorvalds成为其坚定反对者。早期，Linus宁愿选择手工合并代码差异(diff)的方式维护Linux，然而这种方式效率低下，无法应对Linux逐渐增长的代码规模。2002年，Linus与BitMover公司达成协议，选择了BitKeeper，一个分布式版本控制工具来进行内核代码版本管理。2005年4月，Linux内核开发团队中的成员试图通过逆向工程解析BitKeeper的内部协议，引发了法律争议。BitMover因此收回Linux社区对BitKeeper的免费使用权。1

Git概述：版本控制系统的前世今生20分布式版本管理迫于压力，Linus决定开发自己的分布式系统，也就是Git。在五天之内，Linus完成了第一条Git提交，使得Git项目本身成为第一个自托管项目，同时标志了Git的诞生。两周之内，Linus完成了第一条Linux在Git上的提交。Git凭借其强大的性能逐渐成为最广泛使用的分布式版本控制系统。1

Git概述：版本控制系统的前世今生21目前，Git早已成为最主流的版本控制工具2017年采用率：69%2021年采用率：93%1

Git概述：分布式版本控制VS集中式版本控制22ComputerAFileComputerBCentralVCSServerFileVersionDatabaseVersion3Version2Version1ServerComputerVersionDatabaseVersion3Version2Version1ComputerBVersionDatabaseVersion3Version2Version1FileComputerAVersionDatabaseVersion3Version2Version1File分布式版本控制集中式版本控制1

Git概述：Git设计目标23速度简单的设计对非线性开发模式的强力支持（允许成千上万个并行开发的分支）完全分布式有能力高效管理类似Linux内核一样的超大规模项目（速度和数据量）2

Git设计原理：三个层面24Git设计原理01底层数据模型Git的本质四类对象03分支机制分支即指针02存储模型基于快照流的存储2

Git设计原理：底层数据模型25Git本质是一个内容寻址文件系统，核心部分是一个依赖于哈希算法的键值对数据库(Key-ValueDataStore)，每个键值对就是一个对象。Blob，数据对象Tree，树对象Commit，提交对象Tag，标签对象Git的四类对象：Value，对象的内容。Key，将待存储的数据与一个头部信息(该头部信息和待存储对象的类型有关)一起做SHA-1校验运算而得的校验和，长度为40个字符。2

Git设计原理：底层数据模型26Git-exampleincludesrcutils.hutils.cREADME.mdmain.cTree对象Tree对象includeTree对象srcBlob对象utils.hBlob对象utils.cBlob对象main.cBlob对象README.mdKey：40位哈希值Value：utils.c对象的摘要信息Key：40位哈希值Value：utils.c文件内容Key：40位哈希值Value：README.md文件内容Key：40位哈希值Value：include、src、README.md、main.c对象的摘要信息Blob对象：与文件一一对应，值为文件内容(但不包括文件名本身)。Tree对象：与目录一一对应，值为目录下所有子对象的摘要信息，即子对象类型(Blob/Tree)、文件/目录名、键值。2

Git设计原理：底层数据模型27README.mdThisisREADME.md映射SHA-1运算KeyValuea068b3BlobGit-example子对象类型|

Key|文件/目录名Tree|e20d9a|srcTree|397b26|includeBlob|6b12d6|main.cBlob|a068b3|README.md映射SHA-1运算KeyValue6516bdTree简写，实际为40位哈希值2

Git设计原理：底层数据模型28SHA-1（SecureHashAlgorithm1）是一种密码学哈希函数，它能够将任意长度的输入数据转换为固定长度(160位，即40个十六进制字符)的唯一哈希值。在Git的内容寻址文件系统中，SHA-1的核心作用是通过确定性映射实现高效的内容存储与检索。SHA-1对输入数据(包括对象内容和头部元数据)生成唯一的"数字指纹"。也就是说相同内容的同类对象其哈希值完全相同，而不同内容或者不同类型的对象，哪怕只有一个字节的差异(如代码中多一个空格)，其哈希值也会完全不同(例如从a1b2c3...变为d4e5f6...)。理论上SHA-1生成的哈希值长度固定为160位(即2160种可能)，而输入数据可以是任意长度，由于输入域远大于输出域，可能存在不同输入对应相同哈希值的冲突。然而实际应用中，2160(约1.46×1048)是一个天文数字，随机数据导致自然碰撞的概率几乎可以忽略。因此可以近似认为使用SHA-1算法生成的哈希值与对象的值是一一对应的。这种属性使得哈希值天然具备数据库主键属性，因而Git可以利用对象的哈希值(Key)快速定位到对象内容(Value)。2

Git设计原理：底层数据模型29快照1快照2快照3Commit对象Commit对象Tree对象Git-exampleTree对象includeTree对象srcBlob对象README.mdBlob对象main.cBlob对象utils.cBlob对象utils.hTree对象Git-exampleBlob对象main.c父对象Commit对象父对象Tree对象Git-exampleTree对象srcBlob对象utils.c修改main.c文件内容修改utils.c内容初始项目内容未变更，可直接复用Tag对象：Tagv0Tag对象：Tagv1.0Commit对象：与提交记录一一对应，值包括：父commit对象的key提交的基本信息（提交者、作者、提交时间等）对应版本的文件根目录，其树对象的keyTag对象：理解为一个“固化的分支”，开发者通常给某个提交打上标签，用于发布某个特定的版本。通过这四种对象以及哈希串联，形成了不可篡改的版本链。通过哈希的引用，未发生变更的对象可以轻易直接复用，无须重新存储。2

Git设计原理：存储模型30Version1Version2Version3Version4Version5文件AΔ1文件B文件CΔ1Δ1Δ2Δ2Δ3文件A文件B文件CA1C1BA2BC1A2B1C2A2B1C3基于差异的存储基于快照的存储版本迭代2

Git设计原理：分支机制31Commit1Commit2Commit3Commit4’Commit5’Commit4Commit5Commit6Commit7HEADmastermastermasterdevdevmergeGit对项目历史记录的存储形式可以抽象为一个由提交(或者说快照)构成的有向无环图(DirectedAcyclicGraph,DAG)Git分支的本质是指向特定提交对象的可变指针。创建分支就是在提交对象上生成一个新的可移动指针。切换分支就是修改HEAD指针的指向。销毁分支就是删除指针。一个指向分支指针的指针，始终指向当前活跃的分支3

Git工作原理：使用Git前的准备321.安装Git/downloads2.基础身份配置$gitconfig--global"<user-name>"$gitconfig--globaluser.email<user-email-address>在使用Git前需要通过命令行配置用户名以及邮件信息。这是Git进行提交操作的必要信息。3

Git工作原理：Git初始化33初始化后，每个Git项目中都会出现一个隐藏文件夹.git。无论是从开源代码托管平台克隆到本地的Git项目，还是在本地自行初始化的Git项目，项目根目录下都会有这个隐藏文件夹。.git目录是Git版本库所在的位置，包含了Git版本控制所需的所有数据。初始化一个Git项目：1.进入项目的根目录。2.在当前目录运行“gitinit”命令。3

Git工作原理：.git目录结构解析34目录/文件作用HEAD文件存储指向当前活跃分支的引用路径objects目录存储项目的所有Git对象数据refs目录存储项目的所有Git引用，即分支引用、标签引用、远程引用index文件存储暂存区(StagingArea)内容，暂存区用于暂存已修改的文件。info目录用于存储本地仓库的私有配置或元数据。hooks目录用于存放钩子脚本(Hooks)，这些脚本可以在特定的Git操作(如提交、推送、合并等)前后自动触发，用于自定义或扩展Git的行为。branches目录早期Git版本中，开发者可以在此目录下创建文件，文件名代表远程分支的别名，文件内容为远程仓库的URL。虽然初始化Git仓库时会生成一个branches目录，但该目录已废弃，不再被现代Git版本使用。description文件用于存储仓库的描述信息。config文件当前仓库的本地配置文件，用于定义仓库特定的设置(优先级高于全局和系统级配置).git目录是Git版本库所在的位置，包含了Git版本控制所需的所有数据。3

Git工作原理：Git工作区35Git的三大工作区是其版本控制系统的核心设计，主要包括：工作目录(WorkingDirectory/Workspace)暂存区(StagingArea/Index)版本库(Repository/GitDirectory)3

Git工作原理：Git工作区36未跟踪未修改工作目录已修改暂存区已暂存版本库本地仓库工作区已提交gitrestoregitaddgitaddgitcommitgitrestore--staged删除文件

修改文件工作目录是本地文件系统中可直接编辑的目录，所有文件修改直接在此区域进行，此时修改内容仅保存在磁盘中，与Git版本库无关。用户在工作目录对项目进行修改通过“gitadd”将修改保存到暂存区通过“gitrestore”可以丢弃修改，将指定文件还原到版本库中的最新版本3

Git工作原理：Git工作区37未跟踪未修改工作目录已修改暂存区已暂存版本库本地仓库工作区已提交gitrestoregitaddgitaddgitcommitgitrestore--staged删除文件

修改文件暂存区是中间缓存区域，用于选择性标记要纳入下次提交的修改(通过选择改动以及丢弃改动)，解决了“原子提交”问题。用户将多条修改保存到暂存区后，可以通过将修改“还原”或者选择性提交，例如将针对某一个bug修复的多处代码修改作为一次提交。通过“gitcommit”将修改保存到本地Git版本库中。通过“gitrestore--staged”将保存到暂存区的文件还原。3

Git工作原理：Git工作区38未跟踪未修改工作目录已修改暂存区已暂存版本库本地仓库工作区已提交gitrestoregitaddgitaddgitcommitgitrestore--staged删除文件

修改文件版本库指Git的本地数据库，用于存储项目的完整历史记录(位于.git隐藏目录中)。3

Git工作原理：Git工作区39工作区缓存区本地版本库远程版本库pullcheckoutaddcommitpushfetch/clone3

Git是怎么工作的？40/video/BV1r3411F7kn/?vd_source=2b1c4faec2acc9fee92cf25012faaa3a4

开放式协作：Git基本操作41类型作用命令设置与配置设置与获取帮助gitconfig;githelp获取与创建项目获取一个Git仓库gitinit;gitclone快照基础本地提交过程的工作流中使用的命令gitadd;gitstatus;gitdiff;gitdifftool;gitcommit;gitreset;gitrm;gitmv;gitclean分支与合并分支的查看、创建、切换、合并与销毁gitbranch;gitcheckout;gitmerge;gitmergetool;gitlog;gitstash;gittag项目分享与更新与远程仓库进行交互gitfetch;gitpull;gitpush;gitremote;gitarchive;gitsubmodule检查与比较以人类可读方式读取Git数据gitshow;gitshortlog;gitdescribe调试调试查找代码中的问题gitbisect;gitblame;gitgrep补丁以变更即提交的方式管理分支gitcherry-pick;gitrebase;gitrevert邮件使用邮件维护项目，如生成邮件补丁或应用邮件补丁gitapply;gitam;gitformat-patch;gitimap-send;gitsend-email;gitrequest-pull外部系统与其他的版本控制系统集成gitsvn;gitfast-import管理管理Git仓库、修复仓库内容gitgc;gitfsck;gitreflog;gitfilter-branch4

开放式协作：Git基本操作421.设置与配置Git通过“gitconfig”来帮助设置控制Git外观和行为的变量，通常用户可以进行以下配置：配置用户信息，安装完Git之后，用户必须设置用户名和邮件地址。每一个Git提交都会使用这些信息，它们会写入到用户之后每一次提交中，不可更改。“--global”选项表示该配置对当前用户的所有Git仓库生效。若需为特定项目设置特定的身份信息，可在该项目的目录下执行无“--global”选项的同名命令：配置文本编辑器：当Git需要输入信息时（例如输入提交信息）会调用文本编辑器，在没有配置时会使用操作系统默认的文本编辑器，但用户也可以选择配置自定义编辑器检查配置信息：gitconfig--list命令来列出所有Git当前所有配置信息：$gitconfig--global"<user-name>"$gitconfig--globaluser.email<user-email-address>$gitconfig--globalcore.editor<editor>$gitconfig--list4

开放式协作：Git基本操作432.获取与创建项目Git有两种方式获取一个可用的仓库。即在一个项目目录下创建一个新的仓库来得到一个Git仓库或者从网络上或者其他地方拷贝一个现有的仓库。进入项目根目录，在该目录下运行“gitinit”

就可以将当前目录转变成一个Git仓库：“gitclone”

实际上是一个封装了其他几个命令的命令。它创建了一个新目录，切换到新的目录，然后“gitinit”

初始化一个空的Git仓库，然后为指定的URL添加一个（默认名称为origin的）远程仓库（gitremoteadd），再针对远程仓库执行gitfetch，最后通过gitcheckout将远程仓库的最新提交检出到本地的工作目录。$gitinit$gitclone<URL>4

开放式协作：Git基本操作443.快照基础Git可以使用一系列基础的命令来管理本地工作流，这是版本管理与回溯的基础。“gitstatus”

命令用于显示工作目录及暂存区中不同状态的文件。其中包含了已修改但未暂存，或已经暂存但没有提交的文件并给出一些如何在这些暂存区之间移动文件的提示。“gitadd”

命令将内容从工作目录添加到暂存区（或称为索引（index）区），以备下次提交。“gitcommit”

命令将所有通过gitadd暂存的文件内容在数据库中创建一个持久的快照，然后将当前分支上的分支指针移到其之上。用于比较两个工作区之间的差异或者两个版本之间的差异。$gitdiff$gitstatus$gitadd$gitcommit4

开放式协作：Git基本操作453.快照基础“gitreset”命令用于版本的回退：“--soft”选项，重置后仅版本库中指向的内容回退至上一个快照中的版本，暂存区和工作目录内容不变。“--mixed”选项（默认）版本库和暂存区内容都回退至上一个快照中的文件版本，但工作目录保持不变。“--hard”选项工作目录也将回退到上一个快照中的版本。4

开放式协作：Git基本操作463.快照基础“gitrm”用于删除仓库中的文件，需要区别手动删除文件的方式如使用“rm”命令，这种方式仅仅将文件从工作目录删除，却并未将其从跟踪文件清单中(也即暂存区)删除，此时可以通过选择恢复该文件或者使用“gitrm”彻底将其从暂存区中删除。“gitmv”命令是一个便利命令，用于移动或重命名，实际上该命令等同于运行三条命令：“gitclean”用于从工作目录中移除不想要的未被追踪的文件(例如编译的临时文件或者合并冲突的文件)。使用该命令时需要小心确认，由于这些文件未被跟踪，一旦删除无法找回。默认情况下，该命令移除没有忽略的未跟踪文件，如果文件与.gitignore或其他忽略文件中的模式匹配则不会移除，可通过“-x”选项强制移除，以获取一个干净的目录。$gitclean$gitrm<file>$gitmvREADME.mdREADME#等同于$mvREADME.mdREADME$gitrmREADME.md$gitaddREADME4

开放式协作：Git基本操作474.分支与合并“gitbranch”

命令实际上是某种程度上的分支管理工具。它可以列出你所有的分支、创建新分支、删除分支及重命名分支。“gitcheckout”

命令用来切换分支，或者检出内容到工作目录。如果使用“-b”选项，同时参数为一个新的分支名，则会创建一个新分支并且切换到该分支：“gittag”

命令用来为代码历史记录中的某一个点指定一个永久的书签，一般用于版本发布。$gitbranch//列出本地分支(当前分支前标*)$gitbranch<new-branch-name>[SHA-1]//(基于某提交)创建分支$gitbranch-d<existed-branch-name>//删除分支$gitbranch-m<old-branch-name><new-branch-name>//重命名分支$gitcheckout-bdev$gittag<tag-name><SHA-1>/<branch-name>4

开放式协作：Git基本操作484.分支与合并“gitmerge”用来合并一个或者多个分支到已经检出的分支中。然后它将当前分支指针移动到合并结果上。分支的合并有多种情境。9b84e7efec6af80e15369mastermasterdevmergeHEADHEADdevmaster分支直接前移…0e1536998933050e15369mastermasterfeaturemergeHEADHEADmaster分支前移至“合并”提交5150806featuremaster创建一个新的提交：“合并”c90dec22fc457a963e3c4mastermastertestmgmergeHEADHEADc849127testmgmaster合并暂停，需手动解决冲突并依次暂存、提交完成合并(a)直接前移(b)无冲突合并(c)有冲突合并…4

开放式协作：Git基本操作494.分支与合并9b84e7efec6af80e15369mastermasterdevmergeHEADHEADdevmaster分支直接前移(a)直接前移在“dev”分支上进行修改和提交，然后切换回“master”分支，将“dev”分支上的更新使用“gitmerge”合并到“master”中：此时“dev”分支是“master”的直接后继节点。如图(a)在历史提交的DAG中，从“master”指向的节点直接向后移动可以到达“dev”所指向的节点。这种情况，合并只需要将“master”指针向前推进，移动到“dev”所指向的节点即可。4

开放式协作：Git基本操作504.分支与合并…0e1536998933050e15369mastermasterfeaturemergeHEADHEADmaster分支前移至“合并”提交5150806featuremaster创建一个新的提交：“合并”(b)无冲突合并第二种情况：如果在新分支向前移动时，“master”分支也在向前移动（不同开发人员在两个分支上并行开发）在“feature”分支前移的时候，“master”也在向前移动，在合并时，“master”指向的节点“9893305”并非“feature”指向节点“5150806”的祖先节点。因此Git创建了一个新的提交对象“0e15369”，该提交没有实际的更改内容，仅完成“合并”这一件事。生成新对象后，“master”指针前移，指向该“合并”提交，该“合并”提交有不止一个父提交对象。4

开放式协作：Git基本操作514.分支与合并c90dec22fc457a963e3c4mastermastertestmgmergeHEADHEADc849127testmgmaster合并暂停，需手动解决冲突并依次暂存、提交完成合并(c)有冲突合并…第三种情况：如果在并行开发时，不同分支的开发人员修改了同一处代码（例如同一行），那么合并时将发生冲突：此时Git做了合并，但并未自动地创建一个新的“合并”提交，“合并”过程被暂停。此时用户可以使用“gitstatus”命令查看存在合并冲突的文件并使用编辑器打开冲突文件手动解决冲突（选择其一或另外实现）。在手动解决这些冲突的内容后使用“gitadd”将其添加到暂存区，然后继续使用“gitcommit”对其提交完成合并过程。合并后Git生成一个新的合并提交，该提交指向用户解决冲突后的最新快照。4

开放式协作：Git基本操作524.分支与合并“gitlog”

命令用来展示一个项目的可达历史记录，从最新的提交起排序:默认情况下，它只显示当前所在分支的历史记录，但是可以显示不同的甚至多个头记录或分支以供遍历。此命令通常也用来在提交记录级别显示两个或多个分支之间的差异。如果没有参数，则默认按时间顺序输出所有提交记录，每条记录包含40位哈希值、作者、日期、提交信息。通过灵活指定参数可以筛选、过滤和格式化输出结果。$gitlog-n<limit>$gitlog–oneline$gitlog--pretty=format:<...>4

开放式协作：Git基本操作53gitlog的常见参数：参数作用举例-p/-patch显示每次提交的具体代码差异gitlog-p-stat显示每次提交的统计信息(修改的文件及行数)gitlog-stat--name-only仅显示被修改的文件名gitlog--name-only--no-merges--merges不/仅显示合并提交gitlog--merges--author使用作者过滤提交gitlog--author="Alice"--pretty=format格式化输出gitlog--pretty=format:"%h|%ad|%s"可以从官方文档中获取更详细的参数信息：/book/en/v2/Git-Basics-Viewing-the-Commit-History4

开放式协作：Git基本操作545.项目分享与更新“gitfetch”命令用于将远程仓库中有但是在当前仓库的没有的所有信息拉取下来然后存储在本地数据库中，执行完成后，本地仓库将会拥有该远程仓库中所有分支的引用，可以随时合并或查看.“gitpull”命令可以认为是“gitfetch”和“gitmerge”命令的组合体，使用该命令，Git从指定的远程仓库中抓取内容，然后将其合并进当前所在的分支中。“gitpush”命令将本地的分支推送到目标仓库的某分支，该命令会计算本地Git数据库与远程仓库的差异，然后将差异推送到该仓库中。它需要有验证用户对该远程仓库的写权限，同时如果在上一次获取远程仓库数据到此次推送操作之间有其他开发者向该远程仓库进行了推送，那么在进行推送前需要先拉取更新的数据才可以执行推送操作。$gitfetch<URL>/<remote>$gitpull<URL>/<remote>$gitpush<URL>/<remote><branch>4

开放式协作：Git基本操作555.项目分享与更新“gitremote”命令用于管理与远程仓库交互的记录，它允许用户将仓库地址保存成一个简写句柄，例如“origin”，这样就可以不用每次都输入一长串仓库地址。例如，用户可以使用“gitremote”来添加，修改及查看这些句柄$gitremoteaddorigin<URL>//添加远程分支$gitremoteshoworigin//获取远程分支信息4

开放式协作：Git工作流程56远程仓库工作目录拉取更新/克隆项目修改项目后将文件提交到暂存区暂存区自由选择纳入暂存区的文件以备提交版本库masterfeature历史版本管理推送更新远程协作开发本地仓库分支管理&三大工作区&版本回溯机制初始化仓库Git的工作流程围绕代码的版本管理展开，其核心是通过本地仓库与远程仓库的协作，实现代码的追踪、修改、提交和同步。4

开放式协作：Git工作流程57首先，正如前面所介绍，开发者通过在本地创建一个Git仓库(通过“gitinit”初始化新项目)或克隆现有远程仓库(通过“gitclone<URL>”)获取一个Git项目，这会在本地生成一个包含完整版本历史的版本库，其中包含三大工作区。Git仓库获取克隆到本地的xxHash克隆到本地的tensorflow4

开放式协作：Git工作流程58开发者在本地工作目录自由修改项目(例如修改、删除、增添、移动或重命名)，通过“gitadd”将变更添加到暂存区(可多次添加)，再通过“gitcommit”生成提交。每次提交包含唯一的哈希值、作者、时间戳和提交信息，记录代码变更的目的。此阶段可反复进行，形成本地版本链。同时可以轻易地通过分支(“gitbranch”)来隔离不同功能的开发或修复。完成后通过“gitmerge”合并回主分支。使用“gitcheckout”切换分支。另外可以使用“gitdiff”对比差异，“gitlog”查看历史，便捷地进行版本的追溯与管理。本地开发与版本管理4

开放式协作：Git工作流程59本地仓库通过“gitpush”将提交推送到远程仓库(如GitHub、GitLab)通过“gitpull”/“gitfetch”拉取他人更新。版本回溯本地仓库与远程仓库的交互Git提供多种命令帮助开发者进行版本的回退。若代码出错，可通过“gitreset”回退到历史提交，或通过“gitrevert”生成反向提交撤销变更。标签(“gittag”)可用于标记重要版本(如发布版本v1.0)。和“gitreset”相比，“gitrevert”同样可用于版本回退，但后者是一种安全的版本回退，其原理为在最新变更上新增一条提交以撤销原有的提交，并且保留原有的提交。一般用于团队协作中撤销已公开提交，避免历史重写的风险。4

开放式协作：Git工作流程6001本地三大工作区自由地修改代码，自由控制提交粒度，形成本地版本链，三大工作区机制是实现版本管理的基础。03本地与远程仓库的交互通过克隆、拉取、推送等操作随时与团队保持同步02灵活的分支管理轻量的分支操作使得开发者可以简便地创建、切换、销毁分支，通过分支隔离风险，高效并行开发。04版本可追溯本地版本链以及安全的回退机制确保开发者随时可以回溯到历史版本。Git工作流程通过本地工作区的自由开发、本地与远程仓库的交互、分支的灵活管理以及版本的可追溯性，实现了高效协同开发，构建出清晰、安全的代码演进历史。4

开放式协作：如何理解Clone操作？61“克隆(Clone)”是Git版本控制系统中最基础的操作之一，它的作用是将远程仓库(如GitHub、GitLab等平台上的代码库)完整复制到本地环境。当执行“gitclone<URL>”时，Git会完成以下操作，下载完整项目历史：包括所有提交记录、分支、标签以及代码文件，形成一个与远程仓库完全一致的本地副本；自动关联远程仓库：本地仓库默认与克隆来源的远程仓库建立链接，远程仓库的别名通常为“origin”。后续可通过“gitpush”或“gitpull”、“gitfetch”与远程仓库同步；初始化本地分支：克隆操作会检出远程仓库的默认分支(如“main”或“master”)，并在本地创建对应的同名分支，同时建立本地分支与远程分支的追踪关系。“gitclone<URL><local-directory-name>”可以将远程仓库克隆到指定的本地目录，而非默认的远程仓库名。“-b<branch-name>”仅克隆指定分支的代码和历史，而非默认分支。若项目依赖子模块，“--recurse-submodules”参数可以指定同时克隆主项目和其依赖的子模块代码。“gitclone”支持多种参数，例如：4

开放式协作：如何理解Clone操作？62例如，在GitHub可以简便地复制开源项目用于克隆的URL地址$gitclone/torvalds/linux.git4

开放式协作：如何理解Clone操作？63除GitHub之外，开发者也可能从其他仓库克隆项目，有的项目可能并未托管在GitHub上，而是拥有自己的仓库。例如：$gitclone/$gitclone/wireguard-linux/4

开放式协作：如何理解Fork操作？64“Fork(分叉)”是开源协作和分布式开发中的核心概念，在代码托管平台中广泛使用。它允许用户基于他人的仓库创建一份完全独立的副本，成为自己账户下的新仓库并赋予用户对该副本的完全控制权。CloneGit的本地操作，即将远程仓库的代码和历史复制到本地计算机，但并未在远程平台创建独立仓库。ForkFork是基于托管平台(如GitHub)的操作，其作用是在远程服务器上生成一个与原仓库完全独立的副本，属于执行Fork操作的账户。4

开放式协作：如何理解Fork操作？65原仓库副本仓库Fork/Fetch/Pull托管托管GitHub用户AGitHub用户B属于属于ClonePushPR本地首先，用户B在托管平台点击Fork按钮，将用户A的仓库复制到自己的账户下。接下来将副本仓库Clone到本地，在本地修改代码并提交，然后Push到副本仓库。修改后由用户B在GitHub上选择准备合并的分支，并向原始仓库提交PR，请求合并修改。上游原始仓库拥有者(即用户A)有权决定是否合并下游副本仓库推送的代码。若原始仓库有变更，需将更新拉取到副本仓库，避免代码冲突。Fork的典型工作流程4

开放式协作：如何理解Fork操作？664

开放式协作：如何理解Fork操作？67可以根据需求修改项目名称、描述信息以及选择是否只复制主分支。在自己的账号下创建分叉项目。4

开放式协作：如何理解Fork操作？68Fork可以用于Bug修改，如修复GitHub上的开源项目Bug，可以通过Fork原项目，在Fork的项目上修复Bug然后提交PR；可用于派生项目，例如基于现有项目创建新的开发方向，并长期维护一个特定方向的仓库；可以用于保留重要项目的独立副本；可以在副本中测试新功能。使用Fork时，开发者需要注意，副本仓库不会自动同步原始仓库的更新，如需同步原仓库的更新，需手动拉取更新；另外若原项目有特定许可证(如GPL、MIT)，Fork仓库需遵守其条款。Fork的用途▲注意事项4

开放式协作：如何理解Commit、Pull以及Push操作？69“Commit(提交)”是本地开发版本管理的核心，将工作目录中的改动记录到本地仓库，生成一个快照以及记录变更历史：每个提交包含作者、时间、提交信息和唯一的SHA-1哈希值，从而形成可追溯的版本链。“Pull(拉取)”用于同步远程代码：从远程仓库获取最新代码并合并到本地分支。若远程代码与本地修改冲突，需手动解决冲突后重新提交。“Push(推送)”用于上传本地提交：将本地仓库的提交推送到远程仓库，更新远程分支，推送后，其他开发者可通过“gitpull”以及“gitfetch”获取最新的修改，从而实现代码共享和协作。在Git中，Commit(提交)、Pull(拉取)和Push(推送)同样是开源协作的重要操作。4

开放式协作：实践——简介70相信到这里，你已经学会了Git的下载安装与身份配置、使用Git在本地进行开发、使用Git和远程仓库进行交互的基本工作流程以及相关操作。接下来可以打开头头歌平台的课程，通过一个简单的案例实践，来体会Git的强大功能：/4

开放式协作：实践——简介71任务分为4个关卡，每个关卡设置不同的任务，通过这4个关卡，你将完整地实践Git的基本工作流程，掌握Git的基本操作！4

开放式协作：实践——第1关72第1关：Git本地仓库的初始化与基本操作在这一关中，你需要：在【实验环境1】命令行窗口中运行相关git命令完成身份配置以及初始化一个Git项目的操作。将在【实验环境1】中配置的身份信息填写到【代码文件】的指定位置。4

开放式协作：实践——第1关73第1关：Git本地仓库的初始化与基本操作任务说明：实验环境中已经安装好Git，无须自行安装。任务的默认路径为/data/workspace/myshixun/Git-example，当前路径下已经准备好了一个简单的项目，项目中包含了简单的子目录和项目文件。在该路径下，需要按照关卡任务的要求准确完成实践任务。平台将检测：是否初始化git仓库是否按要求完成项目文件修改是否正确设置身份信息并完成提交4

开放式协作：实践——第1关参考步骤74配置用户名和邮箱用户名邮箱在命令行使用“gitconfig”命令完成用户名和邮箱的配置：4

开放式协作：实践——第1关参考步骤75使用“gitinit”命令将当前项目Git-example初始化为Git项目：初始化命令列出当前目录下文件和子目录可以发现当前目录下出现.git子目录4

开放式协作：实践——第1关参考步骤76刚完成初始化时，项目中所有的代码都未被提交到版本库中，并没有被Git跟踪，因此需要做一个初始提交：1.查看当前工作区状态可以看到当前项目中的文件和目录确实全部没有跟踪2.通过“gitadd.”和“gitcommit”将当前目录中所有的文件提交出现提交成功的信息提示4

开放式协作：实践——第1关参考步骤77根据要求修改指定文件并提交：1.使用vi命令修改文件2.查看当前工作区状态可以发现提示修改后的文件状态为“未暂存”3.将修改的文件添加到暂存区此时