共计 4983 个字符，预计需要花费 13 分钟才能阅读完成。
本文来自
武让 极狐 GitLab 高级解决方案架构师
版本控制，也称为源码管制、代码治理，是跟踪和管理软件代码的工作实际。
随着信息化、数字化技术的倒退，源代码逐步成为企业的外围数据资产。如何治理好代码这个数据资产，是每一个企业都须要思考和解决的问题。
作为数字化时代的先行者，大部分互联网和科技型企业曾经实现或局部实现了这项工作，并借助麻利开发、DevOps 等方法论和工具实现了代码的标准、牢靠治理，以及高效高质的产品交付。
在产业数字化转型，企业 DevOps 转型的大趋势下，近些年有不少传统嵌入式开发的企业开始参加进来。嵌入式与互联网、科技公司有着不同的技术栈、开发模式和交付形式，对他们来说，并不能发挥拿来主义精力，将“前辈”的教训间接复用，须要结合实际状况走出一条不一样的路，而首先要解决的问题就是代码的牢靠治理、高效协同以及高质量交付。
嵌入式开发场景的代码治理特点与诉求
特点
依据我过往工作经验以及接触到的局部客户来看，嵌入式开发场景的次要特点如下：
- 团队规模：团队规模不大，少数在 100 人左右；
- 技术路线：以 C/C++ 为主；
- 开发模式：以瀑布流为主；
- 需要治理：需要绝对简略，相较于利用零碎的简单业务逻辑，嵌入式更多是在跟芯片、元器件打交道；
- 代码大小：较小，少数在 KB 或者 MB 级别；
- 协同形式：以单人开发为主，无需协同；
- 交付频率：较慢，大部分依照月度进行交付；
- 交付形式：固件为主（单片机、下位机等），少部分是可执行程序（上位机）；
- 测试形式：真机烧录手动测试为主，极少团队应用仿真模仿测试；
零碎工具：次要围绕需要治理和代码治理：
- 需要治理：常见有 Word、Excel 等电子文本形式，或应用业余 PLM、ALM 工具，又或是无管理工具；
- 代码治理：以 SVN 为主，或无管理工具，仅依附 U 盘、网盘、文件服务器进行归档和传递。
在这样的背景下，从事嵌入式开发的企业其实也是不紧不慢，安稳度过了一段期间。但在数字化转型的浪潮下，很多企业管理者开始居安思危，心愿借助一些先进的开发和管理模式，帮忙企业和研发团队转型降级。
诉求
如上文所述，嵌入式开发场景的特点决定了他们的工作模式，也带来了一些弊病。简而言之就是 短少治理、不足标准、不成体系。
依据我接触到的客户状况来看，从事嵌入式开发的管理者和研发人员对于治理企业源代码的次要诉求如下：
对立治理：源代码是企业外围资产，有必要进行集中、对立治理：
- 无代码管理工具的团队：须要应用代码管理工具，防止企业源代码失落、泄露；
- 企业存在多套代码管理工具：须要尽可能对立代码管理工具，防止治理不受控或减少治理老本。
- 权限管控：须要实现最根本的无权限、只读、读写、治理等权限调配和管控；
版本控制：需对代码进行版本控制，实现最根本的查看历史记录、查看提交人、进行版本回退等性能：
- 对于开发人员，版本控制提供了一颗“后悔药”，防止代码失落或误删除、误批改后无奈找回；
- 对于管理人员，版本控制提供了一套可追溯、可回退机制，防止人为歹意删除、批改代码等状况，确保企业资产安全可靠。
- 代码标准：须要对开发人员的代码标准进行束缚，防止开发人员上传一些无关要紧的大文件以及不标准的代码提交信息，从而导致性能问题并影响协同效率；
- 代码复用：须要有代码复用的能力，防止企业内反复造轮子，防止雷同性能的代码在多个我的项目中屡次实现；
- 分支策略：须要一套分支策略和工作流，实现单人、多人对于一个我的项目的继续开发、修复、公布，并且能较好的辨别和治理不同的环境和版本，如开发环境、生产环境以及为某客户定制版本；
- 审核机制：需提供一套审核机制，实现代码的评审和确认，未经审核的代码不容许进入代码管理系统，从而进步代码品质，晋升开发团队的综合能力；
- 平安审计：需记录零碎用户在代码管理系统上的行为和操作，便于对一些危险行为进行剖析、追溯和告警，升高代码泄露的危险。
所谓工欲善其事必先利其器，嵌入式开发团队或企业要解决的问题远不止如此，但很多团队抉择先从工具侧动手，基于一个好的工具再缓缓摸索和欠缺其实际形式和治理流程。
嵌入式开发场景的代码管理工具与形式
纵观版本控制系统，即代码管理系统的发展史，大抵分为 4 个期间，它们对应的支流工具如下：
- 1980 年：RCS；
- 1990 年：CVS、VSS、Perforce；
- 2000 年：SVN；
- 2005 年：Git。
毫无疑问，Git 是当下用于源代码治理的支流工具，它的发起人正是 Linux 之父 Linus Torvalds。
早在 2002 年以前，世界各地的 Linux 开发者通过邮件的形式把代码 diff 发送给 Linus 自己，再由他人工评审和合并，效率十分之低下，社区开发者也表白了不满。
援用
而 Linus 十分拥护 CVS、SVN 等集中式的版本控制系统，它们性能较差且必须联网能力应用。在 2002 年至 2005 年这段时间，BitMover 公司受权 Linux 社区收费应用它们的商业化版本控制系统 BitKeeper，然而在 2005 年，Linux 社区的开发人员却试图破解 BitKeeper，导致 BitMover 公司发出使用权。
援用
故事的最初，Linus 自己花了两周工夫用 C 写了一个分布式的版本控制系统，就是 Git。所以 Git 自诞生之日起，就是为了更好的治理 Linux 的外围代码。它跟 Linux 一样也是开源的，并且在社区开发人员的继续奉献下倒退了快二十年。
而 SVN 作为上一代的版本控制系统，开始逐步退出历史舞台，往年 1 月，GitHub 也发表自 2024 年 1 月 8 日起，进行对 Subversion（SVN）的反对。
对于没有应用任何代码管理工具的企业，没有历史累赘，会间接抉择 Git。而大多数的从事嵌入式开发的团队，都在应用上一代的源代码管理工具 SVN，这时候他们要思考的就是 Why 和 How 的问题了。
SVN 与 Git
要思考为什么要或者是否要从 SVN 切换到 Git，最间接的形式就是对它们进行一个比照。
总结一下：
➤ 1. 架构
SVN 是集中式架构，Git 是分布式架构，下图是对它们架构的一个形容。但从架构模式上来看，也不太容易能了解两者的区别，那么能够参考灵活性这项的内容，并且举一个形象的例子，更有助于了解它们显著的差别。
- SVN 像直播，用户必须联网能力观看（提交代码）；
- Git 像网盘，用户能够下载到本地进行观看（本地提交），并且能够进行编辑、流传，有须要时再同步回网盘上（远端同步）。
所以 Git 能满足近程办公、异地办公等长期脱离代码服务器的开发场景，某种意义上更合乎将来协同办公的发展趋势。同时为开发人员在本地进行版本控制提供了可能性，这使得开发人员在有后悔药能够吃的前提下可能在本地进行非稳固性能的开发，等性能绝对稳固后再同步到远端，这为多人协同开发打下了根底，防止不稳固的代码影响到别人。
如果你在应用 SVN，为了解决下面的问题，就不得不多在本地建几个文件夹寄存长期的代码正本，这一点也不优雅。
➤ 2. 平安
因为架构模式的区别，两者在安全可靠方面也有不同的体现：
- SVN 是单正本，除非服务器有备份，否则服务器挂了代码数据就都会失落，可靠性较低；
- Git 是多正本，每个开发人员本地都有一套拷贝，并且蕴含所有历史记录，尽管可能不是最新版本，但产生极其状况时，更容易复原，数据的可靠性更高。
当然，Git 正本数越多，可靠性也就越高，同时存在数据泄露的危险就越高，数据的安全性又面临挑战，这是另外一个话题。好在国内企业对于数据隐衷、数据保护非常重视，大部分传统企业曾经通过 DLP（Data loss prevention 数据泄露爱护）技术实现了对企业外部零碎数据的加密和爱护，如 IP-guard 等工具，这个技术对于 SVN 和 Git 同样无效。
➤ 3. 权限
SVN 和 Git 在权限模型上也有较大的差别：
- SVN 反对对代码库中的 目录进行权限管制；
- Git 只提供 对整个代码库的权限管制，无奈对代码库中的目录进行权限管制。
这是两个工具设计理念引起的差别，也可能是 SVN 用户惟一不违心迁徙到 Git 的理由了。
因为 SVN 反对按目录受权，晚期也没有太多模块化设计的实际，所以 应用 SVN 的用户习惯性的把整个我的项目的所有组件和相干依赖塞进一个仓库，走的是“大仓模式”，再依据须要对目录或整个仓库受权。这又导致 SVN 的仓库广泛臃肿、容量大，加剧了性能问题。
而 Git 的理念是模块化的，提倡解耦，走的是“分仓模式”：
- 如果代码彼此之间的业务和性能逻辑绝对独立，并且可能独立编译，那么就应该放到不同的代码库进行治理和受权；
- 如果代码彼此之间有强依赖，无奈独立编译，那么能够放到一个仓库里，但就没必要进行按目录受权了，因为不具备某些目录权限的开发人员无奈通过编译来验证本人开发的性能是否正确，这样就失去了协同开发的意义。
当然，有些以 Git 为底层的代码管理系统反对对代码库的目录进行写入管制，在肯定水平上补救了这个权限管制的缺失。
➤ 4. 性能
同样也是因为架构模式的区别，两者在性能上也相差甚远，从 C++ 开发人员角度登程：
- SVN 的分支是值类型，创立一个分支就相当于在服务端拷贝一份代码到另一个目录，效率低；
- Git 的分支是指针类型，创立一个分支只是创立代码提交记录的指针，效率高。
正因如此，SVN 的用户基本上不会有多个分支，因为分支越多，性能越差。分支少决定了 SVN 的用户无奈实现多人协同开发，一旦多个开发人员在同一个分支下进行开发，那么产生抵触的概率就会减少，并且相互影响，后提交的人须要解决抵触，强制笼罩后又会影响先提交的人，最初变成比赛游戏。
而在嵌入式开发场景中，一个固件对应多个版本，或者针对不同芯片、不同用户又有定制版本的状况时有发生，又不得不利用分支来进行治理，分支数量一下来，分支间的代码同步和性能问题又开始浮现，堪称是让 SVN 的用户欲罢不能。
Git 与之相同，依附灵便快捷的分支治理形式，配合多种分支策略，能够实现多人协同开发、按环境和版本辨别代码、并尽可能确保通用的代码在不同环境、版本间放弃同步。分支策略自身也决定了研发流程的标准建设，这也是企业关怀的核心内容。
➤ 5. 体验
- SVN 的命令较少，易于学习，操作简略。罕用 TortoiseSVN 这款图形化客户端工具进行操作；
- Git 的命令较多，较难学习，操作绝对简单。相熟命令的开发人员习惯应用命令行进行操作，而对于初学者倡议应用 SourceTree
等图形化客户端或支流 IDE 的 Git 插件来操作。
从学习和应用层面来看，Git 的老本绝对较高，但也有一些升高门槛的办法和工具。相较于架构、模式所带来的变动，操作体验上的变动显得微不足道了。从另一方面来说，Git 也算是开发人员的基本技能，毕竟寰球 94% 的开发人员都在应用 Git 或者会应用 Git。
此外，因为 SVN 反对按文件进行下载，再加上操作简略，非技术人员比方产品经理、项目经理也容易上手应用，所以十分多的 SVN 用户应用 SVN 进行文档治理，比方 Word、Excel 等。
Git 恰恰相反，不反对按文件下载（能够通过局部克隆实现，但对于非技术人员老本略高），必须把整个仓库下载下来，操作也比较复杂，所以当这些用户迁徙到 Git 后，旧文档的治理形式又变成了一个问题。
对于这个问题，文档就应该放在文件服务器（FTP、SMB、NFS、NAS 等）或者文档协同零碎（Wiki、Confluence、腾讯文档、飞书等）上进行治理。放在 SVN 上，在以前的时代尽管可行，但集中式的架构须要在线能力拜访，且大文件使得 SVN 本就有余的性能雪上加霜。此外，当初人们对于文档治理的需要除了治理、存储、版本控制之外，还看重协同，所以如果决定从 SVN 向 Git 进行迁徙，文档的管理模式也须要进行降级。
综上，从 SVN 迁徙到 Git，劣势天然是适应技术倒退的趋势，相较于 SVN 这个曾经没有任何官网反对的上一代产品，有十分多的以 Git 为底层的成熟工具和商业化产品，比方 GitLab / 极狐 GitLab、GitHub、Gerrit 等，能够为企业 DevOps 转型提供更好的反对。而且，Git 能够从根本上解决 SVN 的性能问题，实现更好的研发协同，便于企业建设标准的研发流程。
但问题是除了工具自身和应用体验上的差别，Git 在分仓模式、分支策略、受权模式上还有不同，甚至间接影响研发流程的扭转，这外面有哪些潜在的危险，又该如何去解决，为此我会在后续章节来开展，具体探讨这些问题。
💡 后续推送剧透：
- 分仓、权限与依赖问题
- 基于 Git 进行多仓治理
欢送订阅关注～
