时间：2022年12月02日

作者：小蒋聊技术

邮箱：wei_wei10@163.com

微信：wei_wei10

前言

大家好，欢迎来到小蒋聊技术。小蒋准备和大家一起聊聊技术的那些事。

今天小蒋继续坚持“温故而知新”的落地实践，继续和大家分享《构建高可用Linux服务器》这本部书。

作者在第一章，全面的介绍了Linux服务器。教我们如何查看Linux服务器cpu、内存、磁盘、负载等详情情况。又给我们介绍了Linux服务器的网络配置，以及开源的监控工具nagios。

在后面的章节中，主要在介绍具体的案例，例如VPN在企业中的部署和应用，如何构建企业级邮件系统，等等。那么，我们今天就来分享一个代码版本管理的案例。

代码版本管理

版本管理(Revision  control)是一种软件工程方法，在开发的过程中，确保由不同开发人员编辑的同一档案都得到更新。代码版本管理其实就是我们在日常的开发过程中，将每天、每个阶段、每个功能等要求完成之后，将我们的代码再提供给他人的一种行为。

搭建Linux高可用集群，其实就是为了运行公司这些工作必须要使用的软件系统，例如版本管理。 对于关键业务，停机通常是灾难性的。因为停机带来的损失也是巨大的。咱们先来看一组统计数据：

应用系统	每分钟损失(美元)
呼叫中心(Call Center)	27000
企业资源计划(ERP)系统	13000
供应链管理(SCM)系统	11000
电子商务(eCommerce)系统	10000
客户服务(CustomerServiceCenter)系统	27000

随着企业越来越依赖于信息技术系统，由于系统停机而带来的损失也越拉越大。

很多公司代码版本的管理并不统一，一部分人用SVN，一部分用Git。对于习惯了使用Linux或者Mac命令行的人来说，Git的操作更方便和快捷，但是还有一部Windows的研发人员习惯使用SVN。咱们先来聊聊Git和SVN的区别。

GIT是分布式的

这是GIT和其它非分布式的版本控制系统，例如SVN，CVS等，最核心的区别。需要做一点声明，GIT并不是目前第一个或唯一的分布式版本控制系统。还有一些系统，例如Bitkeeper, Mercurial等，也是运行在分布式模式上的。但GIT在这方面做的更好，而且有更多强大的功能特征。

GIT跟SVN一样有自己的集中式版本库或服务器。但GIT更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库/服务器上chect out代码后会在自己的机器上克隆一个自己的版本库。可以这样说，如果你被困在一个不能连接网络的地方时，就像在飞机上，地下室，电梯里等，你仍然能够提交文件，查看历史版本记录，创建项目分支等。对一些人来说，这好像没多大用处，但当你突然遇到没有网络的环境时，这个将解决你的大麻烦。

同样，这种分布式的操作模式对于开源软件社区的开发来说也是个巨大的恩赐，你不必再像以前那样做出补丁包，通过email方式发送出去，你只需要创建一个分支，向项目团队发送一个推请求。这能让你的代码保持最新，而且不会在传输过程中丢失。github.com就是一个这样的优秀案例。

所以，如果使用Git，一定要按它的分布式特性使用它。

中央版本控制系统：SVN

分布式版本控制系统：Git

存储方式不同

GIT是把内容按元数据方式存储，而SVN是按文件方式存储。所有的资源控制系统都是把文件的元信息隐藏在一个类似.svn,.cvs等的文件夹里。如果你把.git目录的体积大小跟.svn比较，你会发现它们差距很大。因为 .git 目录是处于你的机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分支，版本记录等。

分支的区别

Git 分支廉价，SVN 分支昂贵。在版本管理里，分支是很常使用的功能。在发布版本前，需要发布分支，进行大需求开发，需要 feature 分支，大团队还会有开发分支，稳定分支等。在大团队开发过程中，常常存在创建分支，切换分支的需求。

Git 分支是指针指向某次提交，而 SVN 分支是拷贝的目录。这个特性使 Git 的分支切换非常迅速，且创建成本非常低。

而且 Git 有本地分支，SVN 无本地分支。在实际开发过程中，经常会遇到有些代码没写完，但是需紧急处理其他问题，若我们使用 Git，一定要多用分支特性，它可以创建本地分支存储没写完的代码，待问题处理完后，再回到本地分支继续完成代码。

为什么要用gitlab

我们经常会听见一些名称，比如Git、gitLab、gitHub。咱们先看看这些的定义：

Git-它是一个源代码版本控制系统，可让您在本地跟踪更改并从远程资源推送或拉取更改。

GitLab、GitHub是提供对 Git 存储库的远程访问的服务。除了托管您的代码，这些服务还提供旨在帮助管理软件开发生命周期的附加功能。这些附加功能包括管理不同人之间的代码共享、错误跟踪、wiki和其他"社交编码"工具。

1. GitHub 是一项公开可用的免费服务，要求所有代码（除非您有付费帐户）都开放。任何人都可以看到您推送到 GitHub 的代码并提供改进建议。 GitHub 目前托管着数以万计的开源项目的源代码。一般直接在公网使用。
2. GitLab 是一种类似于 github 的服务，组织可以使用它来提供 git 存储库的内部管理。它是一个自托管的 Git 存储库管理系统，可以保护用户代码的私密性，并且可以轻松部署代码的更改，并允许您免费决定它们是公开的还是私有的。一般公司都会选用GitLab来做公司版本控制私服。

特点：

1. GitLab 免费托管您的（私人）软件项目。
2. GitLab 是一个管理 Git 存储库的平台。
3. GitLab 提供免费的公共和私有存储库、问题跟踪和 wiki。
4. GitLab 是位于 Git 之上的，有用户友好的 Web 界面层，可提高使用 Git 的速度。
5. GitLab 提供自己的持续集成 (CI) 系统来管理项目，并提供用户界面以及 GitLab 的其他功能。

总结

其实gitlab的核心还是提供了一种简单、透明和有效的 git 工作方式，并与问题跟踪系统相结合。

使用版本控制中常见的问题是，随着时间推移，产生越来越多的分支，在那些长期维护的分支中充斥着杂乱的修改内容。

git 工作流主要的问题是：

一、默认的 master 分支只是用于发布，开发都在其他分支上。

二、对于多数应用来说过于复杂，特别是 release 和 hotfix 分支的不可部署导致使用上的复杂。

GitLab 工作流的最大原则叫做"上游优先"（upsteam first），即只存在一个主分支master，它是所有其他分支的"上游"。只有上游分支采纳的代码变化，才能应用到其他分支。

对于"持续发布"的项目，它建议在master分支以外，再建立不同的环境分支。比如，"开发环境"的分支是master，"预发环境"的分支是pre-production，"生产环境"的分支是production。

开发分支是预发分支的"上游"，预发分支又是生产分支的"上游"。代码的变化，必须由"上游"向"下游"发展。比如，生产环境出现了bug，这时就要新建一个功能分支，先把它合并到master，确认没有问题，再cherry-pick到pre-production，这一步也没有问题，才进入production。

只有紧急情况，才允许跳过上游，直接合并到下游分支。

GitLab在理解上虽然需要花一些时间，但是Gitlab的理念对于项目管理来说有很大的提升，小蒋个人认为这个付出是值得的。

年龄的增长不可怕，可怕的是从未成长！

感谢大家支持小蒋，小蒋希望和大家共同成长，谢谢。