版本控制

　　如果说什么是软件开发项目一定要使用的基础工具，那么版本控制系统应该算最重要的部分。不管是个人开发或是团队协作开发，都可以通过版本控制系统获得巨大的好处。 　　没有版本控制系统的话，代码可能被别人或自己不小心覆盖或遗失、也不知道是谁因为什么原因改了这段代码、也没办法可以复原回前几天的修改。有了版本控制系统，开发人员只要将每次程式码的变更都纪录（Commit）起来，并且透过版本控制系统中进行更新。 　　有了版本控制系统，我们可以浏览所有开发的历史纪录，掌握团队的开发进度，而且作任何修改都不再害怕，因为你可以轻易的复原回之前正常的版本。我们也可以透过分支和标签的功能来进行软件发行的不同版本，例如稳定版本、维护版本和开发中版本。 　　很多项目需求方还没有明白开发的定义，这里必须要跟大家说一点老生常谈的段子：“开发永远是个过程，而不是结果。”所以开发者一定要使用版本控制系统，Git或Mercurial是免费开源的版本系统系统、随处可用的网络、便宜的云端服务器，甚至有现成的第三方服务Github。 　　如果你还没有使用的话，建议马上为你的软件开发项目建立版本控制。接下来是几点使用版本控制系统的建议： 　　1.将所有东西都放进版本控制系统 　　是的，所有项目开发过程中的产出物都放到版本控制系统之中，这包括了程序源代码、测试程序、文件、设定档、各种自动化脚本等等

https://www.cnblogs.com/xuecanmeng/p/7382975.html 来源： https://www.cnblogs.com/clement-chiu/p/11318094.html

Git，主讲：汤小洋 一、版本控制系统 1. 简介 ​ Version Control System，简称为VCS，版本控制系统是一种记录一个或多个文件的内容变化，以便将来查阅特定版本的内容变化情况的系统。 ​ 简单来说，就是用来保存文件内容变更记录的系统，可以将文件回退到过去某个时间点的状态。 2. 作用 查阅文件的修改记录，如：修改者、修改时间、修改的文件内容等 对比不同版本中文件的变化细节 将文件回溯到之前的某个状态 3. 种类 ​ 版本控制系统的种类： 本地版本控制系统 版本库存放在本地磁盘上 缺点：无法协同开发 集中化版本控制系统 版本库集中存放在中央服务器上，所有参与人员都连接到该服务器，实现协同开发 缺点：自己电脑上没有版本库，本地无法进行版本管理，必须连接中央服务器才能进行版本控制，如果中央服务器宕机，则无法工作 代表应用：Subversion（SVN） 分布式版本控制系统 每个人的电脑上都是一个完整的版本库，在本地就可以进行版本管理，无需连网 但一般都会通过远程仓库来交换版本的修改 代表应用：Git 二、Git简介 1. Git是什么 ​ Git是一个开源的分布式版本控制系统，用来进行项目版本管理 ​ 其实就是一个软件， 由一组命令组成，能够对项目代码进行版本控制 2. 工作流程 基本流程： 使用git命令将远程仓库上的文件克隆到本地仓库中

近年来，随着越来越多的企业从传统经济向数字经济转型，云已经渐渐成为数据经济IT新常态。核心业务系统上云，云上的业务创新，这些都产生了大量的业务数据，这些数据也成为了企业最重要的资产、资源。 阿里云基于OSS的云上统一数据保护方案2.0，针对业务上云后数据保护所面临的挑战，提供多层次、全方位的数据保护解决方案，让您业务上云，数据无忧。 阿里云基于OSS的云上统一数据保护方案2.0，能够应对数据在使用、存储的过程中遇到的风险，通过其云原生的基础能力，为企业提供了多元化、多维度的数据保护解决方案。 业界领先的分布式存储系统，建立稳健的数据底座 阿里云OSS基于业界领先的分布式存储系统构建强健的底座，在设计时充分考虑了存储介质失效、故障的可能性，采用碎片化分布式离散存储技术存储用户的数据，每一份在云端的数据都会被分块，每个分块文件会存多副本，分布于不同机架上，不同交换机下的服务器上，并引入分钟级别的自动维护机制。当某块硬盘发生异常时，对象存储系统将根据风险均衡策略，自动选择合适的硬盘重建数据，从而有效保证对象存储系统级的数据安全。某个服务器，甚至整个机柜出现故障，数据均不会丢失。 同城冗余存储有效抵御机房级故障，满足关键业务数据的同城高可用的要求 对于关键业务数据的同城高可用的要求，阿里云通过OSS同城冗余存储将冗余数据分布于同城的多个可用区上，其采用的是跨可用区分布式纠删码技术

我在API设计中收到的最常见问题之一就是如何对API进行版本控制。虽然并非所有API都完全相同，但我发现在API版本控制方面，某些模式和实践适用于大多数团队。我已经将这些内容收集起来，下面将提供一些关于版本控制策略的建议，该策略将帮助大多数API提供商，无论他们是向内部署API，还是对外的API。 API 版本真的那么重要吗？ API是你与API使用者之间建立的纽带。正常情况下，你们之间的纽带不会轻易的断开。纽带包括URI模式，有效负载结构，字段和参数名称，预期行为以及其他内容。这种方法的最大好处是显而易见的：API使用者的理解不会变更，应用程序可以保证持续有效。 但是，永久不变是不现实的。有时因为业务变化，你可能需要对API进行重大改变。发生这种情况时，最好的方式是，你确保不会做任何会导致API使用者修复代码的事情。 打破与不间断的变化 非破坏性变更往往就像是“添加剂”，一般是添加新字段或嵌套资源到资源陈述，又或是增加新的端点，如PUT或PATCH。API使用者从一开始应该构建能够适应这些非破坏性更改的客户端代码。 突破性变化包括： 1.名字段或资源路径，通常在API发布后为了统一命名规范。 2.更改有效负载结构，一般是适应以下内容： a.重命名或删除字段 b.将字段从单个值更改为一对多关系（比如从一个帐户的一个电子邮件地址移动到这个帐户的电子邮件地址列表）。 c