版本管理

需求 移动互联网时代的到来，软件开发的模式也在变化。记得以前做B/S的后台开发，基本上没有Http接口一说，全部是通过渲染模板技术（jsp,freemark）把最终html展示给最终用户。现在完全变了，基于后台接口提供方，我们从来不是针对只是浏览器展示的后台输出，而是各种终端，比如android,ios。所以设计接口的时候一定要小心，一旦放出去的接口可能就永远都难以变动（除非你强制客户端用户升级）。我们知道， Restful API 已经成为接口设计的一个业务准则。如果你还不是很清楚什么是Restful，推荐你看一下这篇文章： RESTful API 设计指南 。其实，我们就是设计一套基于http协议的业务接口，但是随着时间变迁，业务的变化，或者我们协议本身的优化，都有可能要改变之前存在的接口。这时候给所有接口进行版本管理就显得很重要了，比如某个添加用户的接口，由于业务发展很大，接口的字段属性变化很大，只能重新定义一个新的接口，由 /v1/user/add 变成了 /v2/user/add，这样我们就要维护两套接口的逻辑，映射到代码里，就是要维护两个不同的业务方法。所以这篇文章主要讲的是基于SpringMVC开发的应用，怎么通过扩展开发来方便我们在代码层级管理各不同的版本接口。 SpringMVC原理概述 SpringMVC核心思想就是通过一个servlet

#0 系列目录# 版本管理 SVN版本管理：场景命令实战 SVN版本管理：两种开发模式 #1 SVN标准目录# Subversion有一个很标准的目录结构，是这样的。比如项目是proj，svn地址为 svn://proj/，那么标准的svn布局是： 这是一个标准的布局，trunk为主开发目录，branches为分支开发目录，tags为tag存档目录（不允许修改）。但是具体这几个目录应该如何使用，svn并没有明确的规范，更多的还是用户自己的习惯。 trunk：主干，如果说把一个软件项目从开始到消亡比作一个故事的话，主线情节都在这里被SVN记录着。 branches：分支，有很多种用法，比如：版本发布维护分支、新特性开发分支，甚至是缺陷修复分支等等。 tags：标签，或者叫快照，某个版本发布时候，都在这里留档。 示例如图： #2 集中式：trunk进行主要开发# 一般的， 我们的所有的开发都是基于trunk进行开发 ，当一个版本/release开发告一段落（开发、测试、文档、制作安装程序、打包等）结束后，代码处于冻结状态（人为规定，可以通过hook来进行管理）。 此时应该基于当前冻结的代码库，打tag 。当下一个版本/阶段的开发任务开始，继续在trunk进行开发。 此时，如果发现了上一个已发行版本（Released Version）有一些bug，或者一些很急迫的功能要求

有状态应用编排 StatefulSet 本文将主要分享以下四方面的内容： “有状态”需求 用例解读 操作演示 架构设计 “有状态”需求 课程回顾 我们之前讲到过 Deployment 作为一个应用编排管理工具，它为我们提供了哪些功能？ 如下图所示： 首先它支持定义一组 Pod 的期望数量，Controller 会为我们维持 Pod 的数量在期望的版本以及期望的数量； 第二它支持配置 Pod 发布方式，配置完成后 Controller 会按照我们给出的策略来更新 Pod，同时在更新的过程中，也会保证不可用 Pod 数量在我们定义的范围内； 第三，如果我们在发布的过程中遇到问题，Deployment 也支持一键来回滚。 可以简单地说， Deployment 认为：它管理的所有相同版本的 Pod 都是一模一样的副本。 也就是说，在 Deployment Controller 看来，所有相同版本的 Pod，不管是里面部署的应用还是行为，都是完全相同的。 这样一种能力对于无状态应用是支持满足的，如果我们遇到一些有状态应用呢？ 需求分析 比如下图所示的一些需求： 以上的这些需求都是 Deployment 无法满足的，因此 Kubernetes 社区为我们提供了一个叫 StatefulSet 的资源，用来管理有状态应用。 StatefulSet：主要面向有状态应用管理的控制器

一，了解git 1，git是什么？ Git是目前世界上最先进的分布式版本控制系统（没有之一），由Linus公司（创建了开源的linux）开发而成。 2，分布式版本控制系统是什么意思？具体表现在哪？ Git就是分布式管理系统，于其对应的集中式版本控制系统有SVN，简单的说，分布式的版本控制就是每个人都可以创建一个独立的代码仓库，用于管理，各种版本控制的操作都可以在本地完成，每个人修改的代码都可以合并推送到另一个代码仓库中。 而像SVN这样，只有一个中央服务器，所有的开发人员都必须依赖与这个代码仓库，每次版本控制的操作也必须连接到服务器才能完成，很多公司喜欢用集中式的版本控制是为了更好的控制代码，如果个人开发，一般选择git这种分布式系统。 3，git的作用？ 举个例子：如果你使用word文件编写一个东西的时候，肯定有这样一个经历，想要删除一个段落，但是想要恢复删除的段落，又怕找不回来了，这时候你可能会将这个文件另存一份，然后接着改，改到一定程度，又接着改，如果一直这样下去，可能你满桌面都是个word文档的修改版，等过了一周你想要找回被是删除的文字，但是已经记不清楚删除前保存在哪个文件里面了，只好一个一个去找，这就比较麻烦了。 于是你想，如果有一个软件，不但能自动帮我记录每次文件的改动，还可以让同事协作编辑，这样就不用自己管理一堆类似的文件了，也不需要把文件传来传去。如果想查看某次改动

一、简介 supervisord的官网： http://supervisord.org 。 看懂英文的可以不用看我的博客，直接看文档就行了，文档写得非常好。点个赞！！　　 Supervisor是一个客户/服务器系统，它可以在类Unix系统中管理控制大量进程。Supervisor使用python开发，有多年历史，目前很多生产环境下的服务器都在使用Supervisor。 Supervisor的服务器端称为supervisord，主要负责在启动自身时启动管理的子进程，响应客户端的命令，重启崩溃或退出的子进程，记录子进程stdout和stderr输出，生成和处理子进程生命周期中的事件。可以在一个配置文件中配置相关参数，包括Supervisord自身的状态，其管理的各个子进程的相关属性。配置文件一般位于/etc/supervisord.conf。 Supervisor的客户端称为supervisorctl，它提供了一个类shell的接口（即命令行）来使用supervisord服务端提供的功能。通过supervisorctl，用户可以连接到supervisord服务器进程，获得服务器进程控制的子进程的状态，启动和停止子进程，获得正在运行的进程列表。客户端通过Unix域套接字或者TCP套接字与服务端进行通信，服务器端具有身份凭证认证机制，可以有效提升安全性。当客户端和服务器位于同一台机器上时

一、Git vs SVN Git 和 SVN 孰优孰好，每个人有不同的体验。 Git是分布式的，SVN是集中式的 这是 Git 和 SVN 最大的区别。若能掌握这个概念，两者区别基本搞懂大半。因为 Git 是分布式的，所以 Git 支持离线工作，在本地可以进行很多操作，包括接下来将要重磅推出的分支功能。而 SVN 必须联网才能正常工作。 Git复杂概念多，SVN简单易上手 所有同时掌握 Git 和 SVN 的开发者都必须承认，Git 的命令实在太多了，日常工作需要掌握add,commit,status,fetch,push,rebase等，若要熟练掌握，还必须掌握rebase和merge的区别，fetch和pull的区别等，除此之外，还有cherry-pick，submodule，stash等功能，仅是这些名词听着都很绕。 在易用性这方面，SVN对于新手来说会更有好一些。但是从另外一方面看，Git 命令多意味着功能多，若我们能掌握大部分 Git 的功能，体会到其中的奥妙，会发现再也回不去 SVN 的时代了。 Git分支廉价，SVN分支昂贵 在版本管理里，分支是很常使用的功能。在发布版本前，需要发布分支，进行大需求开发，需要 feature 分支，大团队还会有开发分支，稳定分支等。在大团队开发过程中，常常存在创建分支，切换分支的要求。 Git 分支是指针指向某次提交，而 SVN

版本控制系统 为什么要有版本控制系统 通过注册与登录的需求引入版本控制系统 在开发过程中，经常需要对一个文件进行修改甚至删除，但是我们又希望能够保存这个文件的历史记录，如果通过备份，那么管理起来会非常的复杂。 在多人开发时，如果需要多人合作开发一个页面，那么修改以及合并也会非常的棘手。容易出现冲突。 什么是版本控制系统 版本控制系统（Version Control System）:是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。 版本控制系统不仅可以应用于软件源代码的文本文件，而且可以对任何类型的文件进行版本控制。 【使用webstorm演示版本控制系统】 版本控制系统的分类 参考文章： 关于版本控制的介绍 本地版本控制系统 本地版本控制系统就是在一台机器上，记录版本的不同变化，保证内容不会丢失 如果多人开发，每个人都在不同的系统和电脑上开发，没办法协同工作。 ​ 集中式版本控制系統 svn是集中式的版本控制系统，集中式版本控制系统都有一个单一的集中管理的服务器（中央服务器），保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。 需要一个中央服务器来管理代码的的版本和备份 所有的用户电脑都是从中央服务器获取代码或者是将本地的代码提交到中央服务器 依赖与网络环境，如果连不上中央服务器，就无法提交和获取代码。

　　使用背景: 项目中使用了jquery-weui的左滑删除组件，但在苹果上使用会有左滑点击穿透的现象，只能改源码了。 在github上找，发现是gulp构建的，但版本很低，对于node版本大概要4.5.0才行，本机node版本过高用不了，所以把 node卸载了装nvm来管理。 　　使用步骤： 　　　　1. 卸载本机node 　　　　2. 安装nvm 安装路径不要有空格 下载地址: https://github.com/coreybutler/nvm-windows/releases 　　　　3. 直接使用nvm安装node会很慢，所以先设置镜像，去nvm安装路径下settings文件添加以下地址 　　　　　　node_mirror: https://npm.taobao.org/mirrors/node/ 　　　　　　npm_mirror: https://npm.taobao.org/mirrors/npm/ 　　　　4. 在命令行使用命令： nvm install 12.4.0 安装对应版本就好，这里是安装12.4.0 　　　　5. nvm list命令是查看node版本 　　　　6. nvm use [版本号] 是切换node版本 　　　　7. 用node -v即可查看node版本是否切换成功，接下来就是node正常使用了 来源： https://www.cnblogs

一、冲突解决 Beyond Compare软件 下载BCompare软件，并安装。 删除安装目录下的BCUnrar.dll文件。 使用码： w4G-in5u3SH75RoB3VZIX8htiZgw4ELilwvPcHAIQWfwfXv5n0IHDp5hv 1BM3+H1XygMtiE0-JBgacjE9tz33sIh542EmsGs1yg638UxVfmWqNLqu- Zw91XxNEiZF7DC7-iV1XbSfsgxI8Tvqr-ZMTxlGCJU+2YLveAc-YXs8ci RTtssts7leEbJ979H5v+G0sw-FwP9bjvE4GCJ8oj+jtlp7wFmpVdzovEh v5Vg3dMqhqTiQHKfmHjYbb0o5OUxq0jOWxg5NKim9dhCVF+avO6mDeRNc OYpl7BatIcd6tsiwdhHKRnyGshyVEjSgRCRY11IgyvdRPnbW8UOVULuTE View Code 二、gitflow工作流 1.标准工作流 在实际的项目开发中，有一套规范的gitflow工作流。如下图所示： 注： A、B两个功能分别由两个开发者负责。而Leader来负责代码的Review以及合并。由测试组来进行专业测试。 流程解释： 1）从稳定版本V1中创建dev分支，用于全权管理新功能开发（由Leader管理）。 2

一、分支 1.git中如何保存版本 在我们以往使用文件来进行版本控制的时候，都是将上一个版本复制一份，然后在其基础上进行修改。 但在git中，git只保存当前版本和上一个版本之间的差异，这样可以节省存储空间， 在生成版本的时候速度也会更快。 2.Master主线 如下图所示： 当只有一条主线Master时，新版本都是在上一个版本的基础上进行修改的，例如Version2在Version1的100个文件基础上，新增了20个文件，并修改了其中10个文件。 也就是说Version2只需要保存新增的20个文件，以及修改的10个文件的修改信息，当我们需要Version2的时候，git再去Version1中拿未修改的90个文件。 同理，Version3、Version4也是如此。 3.分支概念 当我们需要已某个版本作为基准，同时开发多个新功能，则可能在该基准版本处产生分支，如下图所示： 处理线上系统的紧急BUG： 例如，Version3是已上线的版本， 我们在Version3的基础上开发新功能： Version3突然出现紧急BUG，需要修复，怎么办？我们可以在Version3的基础上新开一个分支，专门用作BUG修复，修复完后合并到主分支： 而负责新功能开发的分支，可以继续研发新功能，不受影响。等到新功能开发测试完毕后，也可以合并到主分支Master中去。 4.创建分支（开发新功能） 1