Git通讲-第二章(4):分布式版本控制

前言

也是到第二章的第四篇了,这篇我希望能结合前面讲到的快照模型、不可变数据对象、分支模型的知识,来探讨Git是如何实现分布式这件事情的,或许会捎带嘴的提一下Github之类远程托管仓库平台的兴起。

Git分布式版本控制的实现

Git的分布式版本控制系统与传统的集中式版本控制(如SVN)相比,有几个关键的不同点。Git的架构使得每个开发者的本地仓库不仅仅是一个工作副本,而是一个完整的仓库,包含了项目的所有历史记录。这种设计带来了灵活的协作模式和极大的独立性。以下是Git分布式版本控制的一些关键点:

1. 本地完整仓库

  • 完整性:在Git中,每个开发者的本地仓库都是项目完整的历史副本,包括所有的提交记录、分支、标签等。这意味着,开发者在本地可以进行几乎所有的操作,比如查看历史、创建分支、提交代码等,而不需要连接到远程服务器。
  • 独立性:开发者不需要依赖中央服务器,甚至在没有网络连接的情况下也可以正常工作。这种离线工作的能力在许多场景下非常有用,尤其是在网络不稳定的环境中。
  • 优势:即使没有网络连接,开发者也可以进行提交、分支创建、查看历史等操作,而不依赖于中央服务器。

2. 数据完整性和安全性

  • 不可变的快照:每次提交在Git中都是一个快照(snapshot),它通过哈希值标识唯一存在于历史中,不可更改。这意味着任何数据的改变都会创建一个新的快照,而历史记录始终保持不变。
  • SHA-1校验:Git使用SHA-1生成唯一的对象ID(哈希),确保每个版本快照都不可篡改。这些标识在传输和存储时可以保证数据的完整性,即便是在分布式环境中,不同开发者的对象哈希一致,也表明数据内容相同。
  • 数据安全性:哈希校验机制确保了即使分布式地存储和传输数据,代码内容仍然能保持安全、一致。

3. 分布式数据存储

  • 数据模型 :Git的每个仓库都包含完整的项目快照,通过不可变的哈希标识和压缩存储对象(blob、tree、commit等),Git确保每个对象都是唯一的、完整的。
  • 数据同步:当开发者需要与他人共享代码时,可以将本地仓库推送(push)到远程仓库或从其他仓库拉取(pull)更新。这些操作不会修改历史记录,而是将新的数据添加到已有的记录中。

4. 去中心化的协作方式(分布式协作)

  • 与集中式的区别:集中式版本控制系统通常依赖一个中央服务器,所有代码提交和历史记录都存储在该服务器上,开发者只能从服务器上获取最新代码并提交更改。而在Git中,团队可以使用多个远程仓库,不必有一个单一的中央服务器。
  • 多仓库协作 :开发者可以自由选择要与之同步的远程仓库(比如主仓库、个人的备份仓库,甚至其他开发者的仓库)。通过git remote add命令,Git允许开发者添加多个远程仓库,方便进行多方同步。这种灵活性让开发者能够在不同的仓库间推送或拉取更改,适应各种团队协作模式。
    这一特点的实践我在以前的博文中有详细的讲解过👉Git本地与远程 | 焦糖酒的妙妙屋实际上就是创建本地分支与远程仓库建立联系后变成远程分支,然后进行push、pull等操作。

5. 离线提交和版本管理

  • 离线操作:由于每个本地仓库都是完整的代码库,开发者可以离线进行提交、创建分支、查看历史等操作,这样大大降低了对网络的依赖,尤其是在网络不稳定的环境下。开发者可以在本地进行频繁的提交,形成多个小版本,记录开发过程,等到合适的时候再将这些更改推送到远程仓库。
  • 提高效率:这种本地提交和历史保存的能力极大提高了开发效率,开发者在不确定何时需要同步的情况下,也可以随时保留所有的变更历史。
  • 轻松切换工作流 :由于Git的分布式特性,开发者可以在本地实现完整的开发流程,而不需要频繁与中央仓库通信。
    第一点的离线操作也就是使用本地仓库进行版本控制,Git实际上是有划分三个分区(工作区、暂存区、本地仓库)也可以看我之前写的文章Git基础-CSDN博客头几次写文章比较文字还稚嫩🫡。

6. 分支模型支持并行开发

  • 轻量分支:Git的分支创建和切换非常轻量,分支仅仅是一个指向特定提交的指针。这种设计让开发者能够快速创建、切换分支,进行不同功能的并行开发。
  • 非线性开发:Git支持同时进行多个分支的开发,开发者可以在本地新建分支,完成测试和开发,随后与其他人的代码整合。这种分布式结构使得分支开发变得非常高效,开发者可以在本地完成新功能的开发和测试,不影响其他开发者的进度。

7. 强大的同步机制

  • Push和Pull操作 :在分布式系统中,Git提供了灵活的同步操作,开发者可以通过git push将本地更改推送到远程仓库,或使用git pull从远程仓库拉取其他人的更改。
  • Fetch :Git还提供了git fetch命令,可以获取远程仓库的更改而不立即合并,让开发者有机会在本地查看并决定如何合并代码。这样的灵活性大大减少了合并冲突的可能性,也增加了协作的稳定性。
  • Mergegit merge合并操作能够将分支的并行开发成果整合到一起,自动检测和合并更改,并在冲突出现时提供解决方法。

8. 补丁分享与变基(Rebase)

  • 补丁分享 :Git支持将代码的更改生成补丁文件,通过git format-patch生成的补丁文件可以通过各种方式分享给其他开发者。开发者可以应用补丁进行合并,实现分布式协作。
  • 变基(Rebase) :Git的rebase功能允许开发者将分支的基准更改到其他分支之上,清理历史记录,使之看起来像是线性的。变基在多个开发者并行开发时非常有用,可以让提交历史更加简洁、易读。

9. 多方协作与贡献

  • 去中心化的协作模型:Git的设计不要求有一个"主仓库"或"中央服务器",开发者可以通过多仓库之间的相互拉取和推送进行协作。开源项目中尤其会采用这种方式,多个开发者可以通过拉取彼此的代码、推送到公共仓库等方式来进行协作。
  • 代码审查与拉取请求:在没有GitHub的情况下,开发者可以通过Git的分支和变基操作,手动完成代码审查流程。代码可以通过补丁文件或其他分支共享方式进行讨论和审查。

总结

Git的分布式版本控制赋予开发者本地完整的仓库,使他们在离线环境中也能高效工作,降低了对中央服务器的依赖。同时,Git的轻量分支、变基、补丁共享等特性帮助开发者高效处理并行开发和代码整合。SHA-1哈希值和不可变快照的设计保证了数据的安全性和一致性。这种去中心化的模式不仅适合团队内部的协作开发,也非常适合开源项目的贡献和分布式的代码管理。

远程协作

GitHub 是一个基于 Git 的代码托管和协作平台,允许开发者将代码存储在云端并与他人合作开发。在具体介绍GitHub之前,让我们先看看在它诞生之前,Git是通过什么样的方式实现远程协助的👇

Git主要通过"裸仓库"(bare repository)和分布式的服务器存储方式来实现远程协作。虽然那时候没有像GitHub这样的集中式平台,但团队仍然可以通过手动设置和使用远程仓库实现分布式协作。以下是Git在GitHub出现前常用的协作方式:

1. 裸仓库(Bare Repository)

  • 概念 :裸仓库是一个没有工作目录的Git仓库,用于共享和协作。它仅包含版本数据(即.git目录中的内容),没有实际的项目文件。这种仓库的设置方式可以防止直接在其中进行开发操作,避免了冲突的发生。

  • 用途 :开发团队可以在共享的服务器上创建一个裸仓库,让每个开发者将它作为远程仓库进行操作(如git pushgit pull),从而在裸仓库上共享代码。

  • 设置过程 :裸仓库可以通过以下命令创建:

    bash 复制代码
    git init --bare

    然后开发者将这个仓库作为远程仓库添加到自己的本地仓库,通过它来与其他开发者共享代码。

  • 协作方式:开发者各自在本地开发,通过裸仓库定期推送自己的更改,并拉取其他人推送的更改。这种协作方式虽然没有GitHub的UI方便,但同样可以完成代码同步和协作。

2. 通过SSH协议进行仓库访问

  • SSH远程访问:在没有GitHub的情况下,开发者通常通过SSH连接服务器来访问和操作远程仓库。团队会在一台公共服务器(如团队内部的Linux服务器)上创建一个裸仓库,并为每个成员设置SSH访问权限。

  • 协作流程 :开发者通过设置远程仓库地址,将裸仓库的URL作为origin或其他远程名。SSH允许安全传输数据,而Git通过SSH实现了分布式代码管理。

  • 示例 :例如,某个团队可以在服务器的/opt/repo/project.git目录下创建裸仓库,开发者通过以下命令添加并推送代码:

    bash 复制代码
    git remote add origin user@server:/opt/repo/project.git
    git push origin main

3. 通过Email补丁交换(Email Patch Exchange)

  • 发送补丁 :Git支持通过电子邮件交换补丁。开发者可以使用git format-patch命令生成补丁文件,并通过电子邮件发送给其他成员。接收方可以用git am命令应用补丁,将更改合并到自己的分支中。

  • 使用方式:这种方法在早期的开源项目中非常常见,特别适用于分布式团队。Linus Torvalds在维护Linux内核时也常用此方法来收集开发者的贡献。

  • 示例 :创建补丁并发送的步骤如下:

    bash 复制代码
    git format-patch -1 <commit>
    # 然后开发者可以通过电子邮件发送补丁文件

4. 挂载网络文件系统(NFS、SMB)

  • 共享文件系统:在一些小型团队中,可以通过网络文件系统(如NFS或SMB)来共享仓库。团队将裸仓库放在网络共享文件夹中,开发者可以直接访问该目录并进行操作。
  • 限制:这种方式适合小型团队,且对网络速度有较高要求,无法实现真正的分布式协作。尽管如此,这种方法仍然提供了一种灵活的代码共享方式。

5. 分布式多仓库模型

  • 点对点协作:在没有集中式平台时,开发者可以在各自的机器上建立各自的仓库,通过互相添加对方的仓库作为远程仓库进行协作。这种方式虽然略显复杂,但适合一些特定的分布式开发团队。

  • 例子 :开发者A和B可以直接将对方的仓库添加为远程仓库,通过git fetchgit push来直接共享代码,而无需依赖集中式的服务器。

    bash 复制代码
    git remote add developerB ssh://developerB@hostname:/path/to/repo.git

6. 协作工作流

  • 在没有GitHub的时代,Git的协作工作流更依赖于良好的沟通和手动操作。团队可以制定清晰的分支管理策略(例如将一个稳定分支作为主分支),并约定合并和提交的规范,以避免冲突和版本混乱。

小结

在GitHub诞生之前,Git通过裸仓库、SSH访问、电子邮件补丁、共享文件系统等方式,仍然能够支持分布式开发。虽然这些方法在用户体验和便捷性上不如集中式平台,但它们能够有效地实现代码分发、同步和协作,使得分布式版本控制在小型团队和开源项目中同样有效。

GitHub简史

然后在让我们初略的了解一下github的故事。还是得讲回当初我在B站看到的北游老土的视频GitHub的崛起_哔哩哔哩_bilibili

首先必须需要澄清的一点就是GitHub不是Git的缔造者Linus创造的(我看过有好几篇文章弄错了),GitHub成立于2008年,是由Tom Preston-Werner、Chris Wanstrath、P. J. Hyett和Scott Chacon共同创立的,他们希望通过创建一个更便捷的代码托管和协作平台,来改善开发者的工作流程。以下是GitHub的发展历程和一些关键事件:

1. 2008 - 创立

  • GitHub在2008年正式推出。它基于由Linus Torvalds开发的分布式版本控制系统Git,提供一个图形界面来管理代码库,并且引入了社交元素(如关注、Star和Fork)以鼓励社区的互动和协作。

2. 2009 - 快速增长与开源

  • GitHub因其简便的协作方式而迅速受到开发者欢迎,特别是在开源社区中。开源项目和企业逐渐开始将代码托管在GitHub上,项目的"开源"成为一大亮点。2009年,GitHub用户数突破10万,平台上的开源项目数也迅速增长。

3. 2011 - 成为开发者首选平台

  • GitHub已经成为开发者最受欢迎的代码托管平台之一,吸引了大量个人开发者、开源项目和企业用户。2011年,GitHub的用户数突破百万,许多知名的开源项目,如Ruby on Rails、Node.js等,都在GitHub上托管。

4. 2012 - 推出GitHub Enterprise

  • GitHub为企业用户推出了GitHub Enterprise,这是一种适用于企业内部部署的版本,让公司能够在自己的基础设施上运行GitHub。GitHub Enterprise帮助企业在保障安全的前提下使用GitHub的功能,吸引了大量商业客户。

5. 2014 - 开始全球扩展

  • GitHub在全球范围内扩展,成为世界上最大的代码托管平台之一。此时,GitHub已经吸引了数百万开发者用户,并且逐步增加了如代码审查项目管理安全扫描等功能,以便支持更大规模和更复杂的开发团队的需求。

6. 2015 - 2017 - 开发者友好功能的增多

  • GitHub逐步增强了平台功能,引入了Pull Requests评论、代码评论、组织管理等新特性,并在GitHub Pages和项目文档管理方面不断完善,进一步吸引了开源项目和企业用户。

7. 2018 - 微软收购

  • 2018年6月,微软宣布以75亿美元收购GitHub。这次收购在开发者社区引起了广泛讨论,部分开发者担心GitHub会失去独立性。微软承诺保持GitHub的开放性和独立性,同时对其进行更多投资。之后,GitHub的发展更加多元化,并与微软旗下的Visual Studio等开发工具深度集成。

8. 2019 - GitHub Actions的推出

  • GitHub推出了GitHub Actions,一种CI/CD(持续集成/持续交付)工具,帮助开发者自动化工作流,简化构建、测试和部署过程。GitHub Actions的推出使GitHub在开发流程自动化方面更具竞争力。

9. 2020 - 免费私有仓库与新功能

  • GitHub宣布为所有用户提供免费的私有仓库,并且支持更多的协作功能(如Unlimited Collaborators)。此外,GitHub还推出了GitHub Codespaces,使开发者能够直接在浏览器中编写和调试代码。2020年GitHub还发布了"Copilot",一个基于人工智能的编程助手,帮助开发者更快地编写代码。

10. 2021 - 开源安全性的新方向

  • GitHub对代码安全性和开源供应链安全性提出更高要求,加入了自动漏洞扫描、代码依赖分析等功能。同时,GitHub Sponsors进一步支持开源开发者的资助计划,以帮助开源项目获得经济支持。

11. 目前的发展

  • GitHub不断扩展功能,包括GitHub Packages(用于发布和管理包)、GitHub Discussions(用于项目交流)、更强大的API支持等。GitHub依旧是全球最大的代码托管和协作平台之一,支持数百万开发者、企业和开源项目的需求。

总结

GitHub通过不断创新和优化,不仅成为了开发者社区的核心平台,还推动了全球开源社区的发展,逐渐成为集代码托管、项目管理、安全保障和社区支持于一体的完整开发生态系统。

后记

呼,该篇是第二章的最后一篇文章了,本章系统详细的介绍了Git核心理念的实现机制,真是环环相扣,不得不佩服Linus等开发人员的智慧。同时也简单的拓展了一些关于区块链、GitHub的知识,主要我目前的见识也就这点🫠。

下一章节我会介绍一些前面文章中没讲到的漏网之鱼,既然决定开了这一系列那就尽量做到有始有终,追求知识的全面性。

相关推荐
processflow流程图2 小时前
分布式kettle调度平台v6.4.0新功能介绍
分布式
全栈开发圈2 小时前
干货分享|分布式数据科学工具 Xorbits 的使用
分布式
和你一起去月球3 小时前
TypeScript - 函数(下)
javascript·git·typescript
我不是程序猿儿4 小时前
【GIT】TortoiseGit的变基(Rebase)操作
git
运维&陈同学4 小时前
【zookeeper01】消息队列与微服务之zookeeper工作原理
运维·分布式·微服务·zookeeper·云原生·架构·消息队列
时差9534 小时前
Flink Standalone集群模式安装部署
大数据·分布式·flink·部署
菠萝咕噜肉i4 小时前
超详细:Redis分布式锁
数据库·redis·分布式·缓存·分布式锁
只因在人海中多看了你一眼8 小时前
分布式缓存 + 数据存储 + 消息队列知识体系
分布式·缓存
zhixingheyi_tian10 小时前
Spark 之 Aggregate
大数据·分布式·spark
yyycqupt11 小时前
git使用(一)
git