版本控制系统的演化、Git 分布式版本控制系统概述及工作流程

傷城~ 2022-05-10 07:48 329阅读 0赞

**目录**

本地版本控制系统

集中化版本控制系统

分布式版本控制系统

Git 分布式版本控制概述

Git 版本控制工作流程

--------------------

[Git 官网][Git][关于版本控制][Git][教程][Git]

<table> 
 <tbody> 
  <tr> 
   <td> <p><span style="color:#f33b45;">版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。</span></p> <p>作为程序员通常是对保存着软件源代码的文件作版本控制，但实际上，可以对任何类型的文件进行版本控制。</p> <p>如位图形或网页设计师，可能会需要保存某一幅图片或页面布局文件的所有修订版本，采用版本控制系统（VCS）或 SVN 是个明智的选择。 有了它就可以将某个文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态，可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致怪异问题出现的原因，又是谁在何时报告了某个功能缺陷等等。 使用版本控制系统通常还意味着，就算一时失误把整个项目中的文件改的改删的删，之后照样可以轻松恢复到原先的样子。</p> </td> 
  </tr> 
 </tbody> 
</table>

# 本地版本控制系统 #

1、许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。 这么做唯一的好处就是简单，但是特别容易犯错。 有时候会混淆所在的工作目录，一不小心会写错文件或者覆盖意想外的文件。

2、为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。

![70][]

3、其中最流行的一种叫做 RCS，现今许多计算机系统上都还看得到它的踪影。 甚至在流行的 Mac OS X 系统上安装了开发者工具包之后，也可以使用 `rsc` 命令。 它的工作原理是在硬盘上保存补丁集（补丁是指文件修订前后的变化）；通过应用所有的补丁，可以重新计算出各个版本的文件内容。

# 集中化版本控制系统 #

1、接下来人们又遇到一个问题，如何让在不同系统上的开发者协同工作？ 于是，集中化的版本控制系统（Centralized Version Control Systems，简称 CVCS）应运而生。

2、这类系统，诸如 CVS、Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。 多年以来，这已成为版本控制系统的标准做法。

3、对于 Subversion 可以参考[《SVN》章节][SVN]

![70 1][]

4、这种做法带来了许多好处，特别是相较于老式的本地 VCS 来说。 现在，每个人都可以在一定程度上看到项目中的其他人正在做些什么。 而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。

5、事分两面，有好有坏， 这么做最显而易见的缺点是中央服务器的单点故障。 如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。 如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。 本地版本控制系统也存在类似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。

# 分布式版本控制系统 #

1、于是分布式版本控制系统（Distributed Version Control System，简称 DVCS）面世了。 在这类系统中，像 Git、Mercurial、Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。

![70 2][]

2、更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，就可以在同一个项目中，分别和不同工作小组的人相互协作。 可以根据需要设定不同的协作流程，比如层次模型式的工作流，而这在以前的集中式系统中是无法实现的。

# Git 分布式版本控制概述 #

1、同生活中的许多伟大事物一样，Git 诞生于一个极富纷争大举创新的年代。

2、Linux 内核开源项目有着为数众多的参与者。 绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002年间）。 到 2002 年，整个项目组开始启用一个专有的分布式版本控制系统 BitKeeper 来管理和维护代码。

3、到了 2005 年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了 Linux 内核社区免费使用 BitKeeper 的权力。 这就迫使 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds）基于使用 BitKeeper 时的经验教训，开发出自己的版本系统。 他们对新的系统制订了若干目标：

<table> 
 <tbody> 
  <tr> 
   <td> <p>速度</p> <p>简单的设计</p> <p>对非线性开发模式的强力支持（允许成千上万个并行开发的分支）</p> <p>完全分布式</p> <p>有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）</p> <p>自诞生于 2005 年以来，Git 日臻成熟完善，在高度易用的同时，仍然保留着初期设定的目标。 它的速度飞快，极其适合管理大项目，有着令人难以置信的非线性分支管理系统（参见 Git 分支）</p> </td> 
  </tr> 
 </tbody> 
</table>

4、Git 是目前世界上最先进的分布式版本控制系统，也是一款基于命令行的版本控制软件，但在 Windows 和 Mac 系统上也有几款可用的桌面应用。  
5、Git 由 Linux 之父 Linus Torvalds 开发，GIT 不仅仅是个版本控制系统，它也是个内容管理系统(CMS)、工作管理系统  
版本控制软件 Git 让你可以预览你写过的代码的所有版本。  
6、Git 跟 SVN一样有自己的集中式版本库或服务器，但是 Git 更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库/服务器上 chect out 代码后会在自己的机器上克隆一个跟中心版本库一模一样的本地版本库。  
7、如果被困在一个不能连接网络的地方，Git 仍然能够提交文件，查看 log（历史版本记录），创建项目分支等。  
8、Git 是一款基于命令行的版本控制软件，在 Windows 和 Mac 系统上也有几款可用的桌面应用。

<table> 
 <tbody> 
  <tr> 
   <td>Git官网地址：<a href="https://git-scm.com/" rel="nofollow">https://git-scm.com/</a><br> Git 官方文档教程地址：<a href="https://git-scm.com/book/zh/v2" rel="nofollow">https://git-scm.com/book/zh/v2</a></td> 
  </tr> 
 </tbody> 
</table>

<table>  
 <strong>Git VS Svn</strong>  
 <tbody> 
  <tr> 
   <td>1、最核心的区别是：Git 是分布式，而 SVN 不是<br> 2、Git 把内容按元数据方式存储，而 SVN 是按文件<br> 3、<span style="color:#f33b45;">SVN 断开网络或者断开VPN就无法 commit 代码，但是 Git 可以先 commit 到本地仓库</span><br> 4、Git 克隆一个完整项目的速度非常快，SVN 非常慢</td> 
  </tr> 
 </tbody> 
</table>

# Git 版本控制工作流程 #

![70 3][]

<table> 
 <tbody> 
  <tr> 
   <td> <p>Workspace：工作区</p> <p>Index / Stage：暂存区</p> <p>Repository：仓库区（或本地仓库）</p> <p>Remote：远程仓库</p> </td> 
   <td> <p>git clone：将远程的 Master 分支代码克隆到本地仓库</p> <p>git checkout：切出分支出来开发</p> <p>git add：将文件加入库跟踪区</p> <p>git commit：将库跟踪区改变的代码提交到本地代码库中</p> <p>git push：&nbsp;将本地仓库中的代码提交到远程仓库</p> </td> 
  </tr> 
 </tbody> 
</table>

![70 4][]

<table>  
 <strong>git 分支</strong>  
 <tbody> 
  <tr> 
   <td>主分支</td> 
   <td> <p>master 分支：存放随时可供生产环境中的部署的代码</p> <p>develop 分支：存放当前最新开发成果的分支，当代码足够稳定时可以合并到 master 分支上去。</p> </td> 
  </tr> 
  <tr> 
   <td> <p>&nbsp;</p> <p>辅助分支</p> </td> 
   <td> <p>feature 分支：开发新功能使用，最终合并到 develop 分支或抛弃掉</p> <p>release 分支：做小的缺陷修正、准备发布版本所需的各项说明信息</p> <p>hotfix 分支：代码的紧急修复工作</p> </td> 
  </tr> 
 </tbody> 
</table>

**1）工作区**

1、Workspace：程序员进行开发(改动)的地方，是当前看到的，也是最新的。

2、平常项目开发就是拷贝远程仓库中的一个分支，基于该分支进行开发，在开发过程中就是对工作区的操作。

![70 5][]

**2）暂存区**

1、Index / Stage(暂存区)：.git 目录下的 index文件, 暂存区会记录 git add 添加文件的相关信息(文件名、大小、timestamp…)，不保存文件实体, 通过id指向每个文件实体。

2、可以使用 git status 查看暂存区的状态，暂存区标记了当前工作区中，哪些内容是被 git 管理的。

3、当项目完成某个需求或功能后需要提交到远程仓库，那么第一步就是通过 git add 先提交到暂存区，被 git 管理。

![70 6][]

![70 7][]

**3）本地仓库**

1、Repository（仓库区或本地仓库）：保存了对象被提交过的各个版本，比起工作区和暂存区的内容，它要更旧一些。

2、git commit 后同步 index 的目录树到本地仓库，方便从下一步通过git push 同步本地仓库与远程仓库。

![70 8][]

![70 9][]

3、可以在任何地方新建本地仓库，只需要在目标目录下执行 "git init" 指令，就会将此目录自动初始化为本地仓库，同时它会新建 ".git" 目录

![70 10][]

**4）远程仓库**

1、Remote(远程仓库)的内容可能被分布在多个地点的处于协作关系的本地仓库修改，因此它可能与本地仓库同步，也可能不同步，但是它的内容是最旧的。

<table>  
 <strong>小 结</strong>  
 <tbody> 
  <tr> 
   <td> <p>1、任何对象都是在工作区中诞生和被修改；</p> <p>2、任何修改都是从进入 index 区才开始被版本控制；</p> <p>3、只有把修改提交到本地仓库，该修改才能在仓库中留下痕迹；</p> <p>4、与协作者分享本地的修改，可以把它们 push 到远程仓库来共享。</p> </td> 
  </tr> 
 </tbody> 
</table>

![70 11][]

[Git]: https://git-scm.com/book/zh/v2/%E8%B5%B7%E6%AD%A5-%E5%85%B3%E4%BA%8E%E7%89%88%E6%9C%AC%E6%8E%A7%E5%88%B6
[70]: /images/20220510/6b7f759432fd422caa5d094e848128c7.png
[SVN]: https://blog.csdn.net/wangmx1993328/article/category/8068658
[70 1]: /images/20220510/dd1bd97ad1e24cfdb887fcf24c229f67.png
[70 2]: /images/20220510/7d00ad94226e4ee49cf64ce3570460c0.png
[70 3]: /images/20220510/b6fcac3d28aa472caf28c725945fcda9.png
[70 4]: /images/20220510/2810953e42c64e8ab3f43d16d77f15f9.png
[70 5]: /images/20220510/b3e5a765cfe04fa0b2d6186cbd308a09.png
[70 6]: /images/20220510/a9e1fc5c9ed642b1abe738f0891a286f.png
[70 7]: /images/20220510/8832eb30d6bc42bf920222f34eab8d1e.png
[70 8]: /images/20220510/ba170c704f204cef93d3bb296c72a77e.png
[70 9]: /images/20220510/7fdafbf4db3745eb90ade5460446f06c.png
[70 10]: /images/20220510/4dd91c16f3b3442e80864f7b6f0e22c9.png
[70 11]: /images/20220510/840345f3ed7a4c289bdbee5baeb34119.png