版本管理

API版本管理的重要性不言而喻，对于API的设计者和使用者而言，版本管理都有着非常重要的意义。下面会从WEB API 版本管理的角度提供几种常见办法： 首先，对于API的设计和实现者而言，需要考虑向后兼容性，但是随着业务的发展或需求的变更往往会导致兼容性实现非常复杂，因此引入API版本管理将能解决这个尴尬。下面提供多个版本管理的API实现，不需要再为了向后兼容性而绞尽脑汁。其次，对于API的使用者而言，也可以灵活选择使用不同版本API，而不用担心API的兼容性问题。 WEB API 版本化的五种方式: 方式一：利用URL HTTP GET: https://banbenguanli.com/api/v2/useracount/card 方式二：利用用户自定义的request header HTTP GET: https://banbenguanli.com/api/useracount/card api-version: 2 方式三：利用content type HTTP GET: https://banbenguanli.com/api/useracount/card Accept: application/vnd.banbenguanli.v2+json 方式四：利用content type，把版本号分离出来了 HTTP GET: https://banbenguanli

　　在新公司入职已经一周了，由于刚好在版本空档期，没有什么开发任务，就自己熟悉熟悉代码什么的。 目前公司用的是git，原来公司用的是svn，今天就记录下从小白入门。 　　gitlab分布式版本管理，理论介绍就不说了，我就记录下怎么使用。 git安装 git的初期配置 设置用户名和邮箱 git config --global user.name "用户名" git config --global user.email "邮箱" 是 是 是　 　　 git创建本地仓库 创建本地仓库 语法 ： git init <目录，可以省略，就是当前目录> --例如-------------------------------------------- git init gitTest git init (创建完成之后 会多出一个.git的隐藏文件) 有创建就有删除（其实就是删除.git文件夹即可，哈哈，用毛的命令） 语法 ：rm -r <路径> --例如-------------------------------------------- rm test -r rm -r test 添加文件到索引（就是将文件添加到版本管理中） 语法 ：git add （文件，“.”，通配符：*.txt,）（-p,-i） --例如------------------------------------------

　　Git是分布式版本管理控制的工具。学习Git一般都是先去学习Git的命令。 但是学习完Git的基本命令之后还是不知道怎样使用Git。首先，我们要清楚的 一点是Git的使用方法其实有很多种，也就是说Git有不同的工作流。本文介绍 一下Git常用的三种工作流。 　　1. 集中式工作流 　　　　集中式工作流主要是用于团队人数较少的情况，集中式工作流只在一 个分支上进行开发。每次修改都在同一个分支上提交。像写文档这种工作方式 就可以使用集中式工作流。 　　　　 　　2. Gitflow工作流 　　在软件开发设计中，我们要考虑功能开发、发布准备和维护分配独立，软 件测试等，所以需要多个分支对版本进行管理。这就需要Gitflow工作流的方式。 一般的企业软件开发中使用的也是Git flow工作流。 　　 　　3.Forkking工作流 　　 Forking 工作流是分布式工作流，充分利用了 Git 在分支和克隆上的优势。 可以安全可靠地管理大团队的开发者（ developer ），并能接受不信任贡献者 （ contributor ）的提交。开源项目使用的就是Forkking工作流。 　　 　　总而言之，Git有很多种使用的方式，哪种适合自己就使用哪种方式。 https://github.com/xirong/my-git/blob/master/git-workflow-tutorial

1、概述 微软在2019年5月发布Azure DevOps Server 2019后不到2个月的时间里，就快速准备好了第一个升级包（2019 Update 1），并计划在几周后发布正式版本。也许你还没来得及升级TFS，也许你还在观望，但是这个版本一定会引起你的关注。它不仅修复了Azure DevOps 2019大版本中的缺陷，将软件提升到了前所未有的稳定级别；还在升级包中增加了大量引人注目的新功能，集成了近期微软在Azure DevOps云端发布的大部分成熟功能。下面我们从各功能模块的角度，逐个看看这个升级包的新特性。 2、Boards （工作项） 新增Basic流程模板New Basic process 在之前所有版本的TFS和Azure DevOps Server中，存在三个开箱即用的过程模板（Agile, Scrum和CMMI）。每个过程模板适用于不同的开发管理模式，为开发团队提供强大而灵活的项目交付和跟踪功能。但是，如果开发团队没有使用敏捷或CMMI模式管理自己的开发工作，或者并没有接触过敏捷和CMMI，他们对DevOps Server中这些默认模板中的概念和定义就会变得非常陌生。我们辅导过的许多开发团队，都会说”TFS系统中的概念比较晦涩难懂，如果没有人指导，不知道如何开始。” 为了解决这个问题，在最新版本的Azure DevOps Server 2019.1中

nvm-windows 官网 Node版本管理器--nvm，可以运行在多种操作系统上。nvm for windows 是使用go语言编写的软件。 我电脑使用的是Windows操作系统，所以我要记录下在此操作系统上nvm的安装和使用。 我目前看到有两个版本【Pre-release 1.1.7】和 【Latest release 1.1.6]，我们下载目前稳定版本1.1.6就可以了。1.1.7版本是最新版本，可能还不是很稳定。 而这里又有四个可下载的文件。 nvm-noinstall.zip： 这个是绿色免安装版本，但是使用之前需要配置 nvm-setup.zip：这是一个安装包，下载之后点击安装，无需配置就可以使用，方便。 Source code(zip)：zip压缩的源码 Sourc code(tar.gz)：tar.gz的源码，一般用于*nix系统 我对这个目前只是简单使用，为了方便，所以下载了nvm-set.zip文件。 请注意 ： 在安装nvm for windows之前，你需要卸载任何现有版本的node.js。并且需要删除现有的nodejs安装目录（例如："C:\Program Files\nodejs’）。因为，nvm生成的symlink（符号链接/超链接)不会覆盖现有的（甚至是空的）安装目录。 你还需要删除现有的npm安装位置（例如“C:\Users\weiqinl

问题： Error : svn : E195020 : Cannot merge into mixed - revision working copy [ 241 : 250 ]; try updating first 分析： 提示的是合并代码的版本号有出入，这种情况在使用 AS 开发多个 android 项目时，使用 svn 进行版本管理会出现； 主要是服务器版本号和本地版本号没有同步 如果是一个项目的版本号高于了另外一个项目的版本号，这种情况使用 TortoiseSVN 客户端是可以直接合并同步的； 但是 AS 使用的 TortoiseSVN command line ，稍微有点儿出入 解决方式： 方式一、使用AS 更新代码库，最好是提交完（commited）就及时更新（update） 方式二、直接使用TortoiseSVN对当前项目先执行update, 然后在执行后续操作 转载请标明出处: AS使用SVN管理代码出现 try updating first 文章来源: https://blog.51cto.com/12539515/2389209

名称 描述 1 tcpmux TCP 端口服务多路复用 5 rje 远程作业入口 7 echo Echo 服务 9 discard 用于连接测试的空服务 11 systat 用于列举连接了的端口的系统状态 13 daytime 给请求主机发送日期和时间 17 qotd 给连接了的主机发送每日格言 18 msp 消息发送协议 19 chargen 字符生成服务；发送无止境的字符流 20 ftp-data FTP 数据端口 21 ftp 文件传输协议（FTP）端口；有时被文件服务协议（FSP）使用 22 ssh 安全 Shell（SSH）服务 23 telnet Telnet 服务 25 smtp 简单邮件传输协议（SMTP） 37 time 时间协议 39 rlp 资源定位协议 42 nameserver 互联网名称服务 43 nicname WHOIS 目录服务 49 tacacs 用于基于 TCP/IP 验证和访问的终端访问控制器访问控制系统 50 re-mail-ck 远程邮件检查协议 53 domain 域名服务（如 BIND） 63 whois++ WHOIS++，被扩展了的 WHOIS 服务 67 bootps 引导协议（BOOTP）服务；还被动态主机配置协议（DHCP）服务使用 68 bootpc Bootstrap（BOOTP）客户；还被动态主机配置协议（DHCP

1.SVN服务实战 1) 什么是SVN（Subversion）？ Svn（subversion）是近年来崛起的非常优秀的版本管理工具，与CVS管理工具一样，SVN是一个跨平台的开源的版本控制系统。Svn版本管理工具管理着随时间改变的各种数据。这些数据放置在一个中央资料档案库（repository）中，这个档案库很像一个普通的文件服务器或者FTP服务器，但是，与其他服务器不同的是，SVN会备份并记录每个文件每一次的修改更新变动。这样我们就可以把任意一个时间点的档案恢复到想要的某一个旧的版本，当然也可以直接浏览指定文件的更新历史记录。 为什么会有svn这样一个项目？ 官方解释：为了接管CVS的用户基础，确切的说，我们写了一个新的版本控制系统，它和CVS很相似，但是它修正了以前CVS所没有解决的许多问题。问题见SVN官方首页。 SVN是一个非常通用的软件系统，它常被用来管理程序源码，但是它也可以管理任何类型的文件，如文本，视频，图片等等。 svn版本控制系统是集中式的数据管理，存在一个中央版本库，所有开发人员本地开发所使用的代码都是来自于这个版本库，提交代码也都必须提交到这个中央版本库。 svn版本控制系统工作流程如下： 在中央库上创建或从主干复制一个分支 从中央库check out 下这个分支的代码 增加自己的代码文件，修改现存的代码或删除代码文件 commit代码

#0 系列目录# 版本管理 SVN版本管理：场景命令实战 SVN版本管理：两种开发模式 GIT版本管理：场景命令实战 GIT版本管理：Git Flow模型 #1 Git Flow介绍# 我们都知道, 在 git 的分支功能相对 svn 确实方便许多， 而且也非常推荐使用分支来做开发 . 我的做法是每个项目都有2个分支, master 和 develop. master 分支是主分支, 保证程序有一个 稳定版本 , develop 则是开发用的分支, 几乎所有的功能开发, bug 修复都在这个分支上, 完成后 再合并回 master . 但是情况并不是这么简单. 有时当我们正在开发一个功能, 但程序突然出现 bug 需要及时去修复的时候, 这时要切回 master 分支, 并基于它创建一个 hotfix 分支. 有时我们在开发一个功能时, 需要停下来去开发另一个功能. 而且所有这些问题都出现 的时候, 发布也会成为比较棘手问题. 也就是说, git branch 功能很强大， 但是没有一套模型告诉我们应该怎样在开发的时候善用这些分支 。而Git Flow模型就是要告诉我们怎么更好地使用Git分支。 简单来说， git-flow 就是在 git branch git tag基础上封装出来的代码分支管理模型 ，把实际开发模拟成 master develop feature release

01 背景 由于导航应用中的地图渲染、导航等核心功能对性能要求很高，所以高德地图客户端中大量功能采用 C++ 实现。随着业务的飞速发展，仅地图引擎库就有40多个模块，工程配置极其复杂，原有的构建及持续集成技术已无法满足日益增长的需求变化。 除了以百万计的代码行数带来的复杂度外，高德地图客户端中的 C++ 引擎库工程（以下简称引擎库）的构建和持续集成还面临以下几个挑战： 支持多团队协作：多团队意味着多操作系统多 IDE ，降低不同操作系统和不同 IDE 下的工程配置的难度是重点要解决的难题之一； 支持多业务线定制：引擎库为手机、车机、开放平台等业务线提供支持，而各个业务线的诉求不同，所以需要具备按功能构建的能力； 支持车机环境：在诸多业务线中，高德地图有一个非常特殊的业务线，即车机（AMAP AUTO）。车机直接面对各大车厂和众多设备商，环境多为定制化，构建工具链各式各样。如果针对每个车机环境都定制一套构建配置文件，那么其维护成本将非常高，所以如何用一套构建配置满足车机的多样化构建需求成为亟需解决的问题； 此外，由于历史原因，引擎库中源码和依赖库混杂，都存放于 Git 仓库中，这样会带来两个问题： 随着构建次数不断增加，Git 仓库越来越大，代码与依赖库检出越来越慢，极大影响本地开发以及打包效率； 缺乏统一管理，依赖关系混乱，经常出现因为依赖问题而导致的构建失败