代码管理

版本控制系统 1. 版本控制系统： git 分布式 —没有中心代码库，所有机器之间的地位同等（每台机器上都有相同的代码） svn 集中管理的 —有中心代码库，其他都是客户端 2.git与svn介绍 1.git属于 分布式版本控制系统： 客户端并不只提取最新版本的文件，而是把原始的代码仓库完整地克隆下来。 优点： a.由于任何人每次提取操作，实际上都是一次对代码仓库的完整备份，因此近乎所有的操作都可以在本地执行，速度就是相当的快，并且可以在网络断开的时候操作仍然不受影响，可以频繁的进行提交更新，等到有网络的时候再上传到仓库就可以了。 b.git的分支模型，相当的轻量级，被称为“必杀技”。 　 缺点： a.每个开发人员都拥有所有的代码，不利于核心代码的保密（如果有重要代码需要保密，则不建议使用git） 2.svn属于 集中化的版本控制系统： 有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的成员通过客户端连接到这台服务器，进行文件上传和更新。 优点： a.使用简单，比较符合我们的常规思维 b.同步代码比较简单，只要一步操作即可。 缺点： 丢失数据的风险：由于集中化的特点，如果版本库的服务器磁盘发生故障等，你不能保证所有的数据已经有人提取出来了，最坏的情况是彻底的丢失整个项目的所有历史更改记录。 3.git 相关概念—纯命令行 工作区 版本库 暂存区 HEAD 版本号

01-Git概述（Git历史） Git 诞生于一个极富纷争大举创新的年代。Linux 内核开源项目有着为数众多的参与者。 绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002年间）。 到 2002 年，整个项目组开始启用一个专有的分布式版本控制系统 BitKeeper 来管理和维护代码。 到了 2005 年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了 Linux 内核社区免费使用 BitKeeper 的权力。 这就迫使 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds）基于使用 BitKeeper 时的经验教训，开发出自己的版本系统。 他们对新的系统制订了若干目标： 速度 简单的设计 对非线性开发模式的强力支持（允许成千上万个并行开发的分支） 完全分布式 有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量） gitlab github 码云 02-Git概述（Git与SVN对比） SVN是集中式版本控制系统，版本库是集中放在中央服务器的，而开发人员工作的时候，用的都是自己的电脑，所以首先要从中央服务器下载最新的版本，然后开发，开发完后，需要把自己开发的代码提交到中央服务器。 集中式版本控制工具缺点： 服务器单点故障 容错性差 [

大二下学期也快结束了 ，学习新的课程，在学习过程中我们必然会用到在这个寒假中我所阅读的书籍《梦断代码》中的有用的东西，和在书中展现给我们的道理，作为一个优秀程序员应有的能力和毅力。 《梦断代码》是讲一事，也是讲百千事；是写一软件，也是写百千软件；是写一群人，也是写百千万人。任何一个在软件领域稍有经验的技术人员看完《梦断代码》，必掩卷长叹：做软件难。 管理奇客和狗中，提到了项目经理应有的职责。 为OSAF寻找软件开发经理的工作进展缓慢。尽管居此位者手握大权，却许多程序员不愿为之。 一些程序员厌恶经理； 另一些人认同良好管理的价值，但却不够胆色担此重任。 非正式的技术项目管理方式在惠普的“闲逛式管理”概念达到顶峰，但在软件领域却很不成功，因为开发进度是闲逛的管理人员看不到的。 这告诉我们作为程序员，我们应该做好自己的分内事，没有原因去厌恶其他任何一个人，在有重任在我们肩膀上时，我们应该有胆色，敢于担此重任。只有这样才能让我们的团队立于不败之地！ “对于任何用新技术或新设计的项目，弗里德里克·布鲁克斯建议道：‘准备丢弃一切吧’，因为你大抵不能一次就做对。你所能掌控的，不过是从一开始就有做错的准备，或者干脆‘保证交付垃圾产品给客户’。” 起初我是不太理解这句话，但当我们以团队合作组队做项目的时候，一般项目不是仅仅一个人能完成的工作量以及难度，我们需要学会通力合作

背景 微前端是一种利用微件拆分来达到工程拆分治理的方案，可以解决工程膨胀、开发维护困难等问题。随着前端业务场景越来越复杂，微前端这个概念最近被提起得越来越多，业界也有很多团队开始探索实践并在业务中进行了落地。可以看到，很多团队也遇到了各种各样的问题，但各自也都有着不同的处理方案。诚然，任何技术的实现都要依托业务场景才会变得有意义，所以在阐述美团外卖广告团队的微前端实践之前，我们先来简单介绍一下外卖商家广告端的业务形态。目前，我们开发和维护的系统主要包括三端： PC系统：单门店投放系统PC端 H5系统：单门店投放系统H5端 KA系统：多门店投放系统PC端 如上图所示，原始解决方案的三端由各自独立开发和维护，各自包含所有的业务线，而我们的业务开发情况是： PC端和H5端相同业务线的 基本业务逻辑一致 ，UI差异大。 PC端和KA端相同业务线的 部分业务逻辑一致 ，UI差异小。 在这种特殊的业务场景下，就会出现一个有关开发效率的抉择问题。即我们希望能复用的部分只开发一次，而不是三次。那么接下来，就有两个问题摆在我们面前： 如何进行 物理层面的复用 （不同端的代码在不同地址的Git仓库）。 如何进行 逻辑层面的复用 （不同端的相同逻辑如何使用一份代码进行抽象）。 我们这里重点看一下物理层面的复用，即：如何在物理空间上使得各自独立的三端系统（不同仓库）引入我们的复用层？我们尝试了NPM包

一、实验目的 1、解分布式版本控制系统的核心机理； 2、熟练掌握git的基本指令和分支管理指令； 二、实验内容 1）安装git 2）初始配置git ，git init git status指令 3）掌握git log ,git add ,git diff 指令 4) 掌握git tag git branch，git commit 指令 5）掌握git revert 指令 三、实验记录 实验内容以及结果的截图： 1、安装git； 2、初始配置git、git init、git status指令 在开始使用 Git 之前，你需要配置 Git。在命令行工具中运行以下每行，确保所有选项都已被配置好。 设置你的 Git 用户名 git config --global user.name " " 设置你的 Git 邮箱 git config --global user.email " " 确保 Git 输出内容带有颜色标记 git config --global color.ui auto 对比显示原始状态 git config --global merge.conflictstyle diff3 git config --list 判断仓库的状态： git status 是了解 Git 的核心所在。它将告诉我们 Git 正在考虑什么，以及 Git 所看到的我们仓库的状态。当你第一次使用 Git

实验一 GIT 代码版本管理 实验目的： 　　 1）了解分布式分布式版本控制系统的核心机理； 　　2) 熟练掌握git的基本指令和分支管理指令； 实验内容： 　　 1）安装git 　　2）初始配置git ，git init git status指令 　　3）掌握git log ,git add ,git diff 指令 　　4) 掌握git tag git branch，git commit 指令 　　5）掌握git revert 指令 实验记录： 　　1）初次配置git 2）从头创建仓库 　　 在对 Git 仓库进行 commit 或执行任何其他操作之前，需要一个实际存在的仓库。要使用 Git 新建一个仓库，我们将使用 git init 命令。 　　创建项目目录并使用git init命令 　　克隆现有仓库 　　 在 Git 上进行克隆的方法是调用我们将在终端上运行的命令 git clone，然后传入要克隆的 Git 仓库的路径。 　　首先需要验证终端位置，在克隆任何内容之前，确保命令行工具已定位于正确的目录下。克隆项目会新建一个目录，并将克隆的 Git 仓库放在其中。 　　判断仓库的状态 　　git status 是了解 Git 的核心所在。它将告诉我们 Git 正在考虑什么，以及 Git 所看到的我们仓库的状态。 3）git log 　　使用命令行转到项目的目录下，输入git

公司需要使用阿里提供的kms密钥管理服务，为验证服务能够正常使用。使用公司申请的测试秘钥资源进行测试。 1、使用阿里提供的demo代码，验证能够正常读取、加密、解密功能。 （ps:主要是注意配置的权限问题，基本正常） 2、本地服务验证。 由于规则要求是使用秘钥别名获取信息。所以测试时候也一直用别名带入逻辑运行。 代码操作简略如下： public static byte [ ] encrypt ( String keyId , String msgBuf ) { try { EncryptResponse kmsEncryptResp = encryptByKms ( keyId , msgBuf ) ; //通过KMS加密 String encryptedStr = kmsEncryptResp . getCiphertextBlob ( ) ; //得到密文 byte [ ] encrypted = encryptedStr . getBytes ( CharsetUtil . UTF8 ) ; return encrypted ; } catch ( ClientException eResponse ) { logger . error ( "加密失败，处理失败：{}，错误码：{}，错误描述：{}" , eResponse . getMessage ( ) ,

首先订正下quickstart 的做法：saturn 的job 同时保存在数据库及zookeeper上，修改job不能只修改zookeeper上的数据，都应该通过console的rest api或者界面实现。 executor 不连接数据库，所有对job的修改都是通过zookeeper watcher触发的。 先上一个zookeeper 截图： saturn对job的watcher分布在很多类中，跟踪分析要注意这一点； 对应新增加job是通过watch $jobs来实现的，具体代码在InitNewJobService的如下代码： class InitNewJobListener implements TreeCacheListener { @Override public void childEvent(CuratorFramework client, TreeCacheEvent event) throws Exception { if (event == null) { return; } ChildData data = event.getData(); if (data == null) { return; } String path = data.getPath(); if (path == null || path.equals(JobNodePath.ROOT)) {

作为开源代码库以及版本控制系统，Github拥有140多万开发者用户。随着越来越多的应用程序转移到了云上， Github已经成为了管理软件开发以及发现已有代码的首选方法 。 在Git中并不存在主库这样的概念，每一份复制出的库都可以独立使用，任何两个库之间的不一致之处都可以进行合并。与其它像 SourceForge或Google Code这样的服务不同，GitHub的独特卖点在于从另外一个项目进行分支的简易性。为一个项目贡献代码非常简单：首先点击项目站点的“fork”的按钮，然后将代码检出并将修改加入到刚才分出的代码库中，最后通过内建的“pull request”机制向项目负责人申请代码合并。已经有人将GitHub称为代码玩家的MySpace。 在GitHub进行分支就像在Myspace（或Facebook…）进行交友一样，在社会关系图的节点中不断的连线。 本文介绍如何在Mac下使用Github Desktop这个客户端管理Eclipse开发的项目代码。本文涉及三个主题： 1.注册GitHub帐号； 2.下载安装Mac版Github Desktop客户端； 3.让Eclipse与Github Desktop协作。 一、注册GitHub帐号 1.访问官方注册地址： https://github.com ，填写你的昵称、登陆邮箱和密码后点击“Sign up for GitHub”按钮

基于weiphp框架的留言板插件教程： 1、功能分析 传统的留言板应该具有发布留言、查看留言、回复留言、管理留言等功能，本教程开发的是最基本的留言板，仅包含发布留言和查看留言两个功能，根据功能用bootstrap制作的前台页面样式如下： 2、新建weiphp插件 在第一步我们根据留言板的功能需求设计了前台效果页面，那么接下来的步骤就是根据效果来逐步开发weiphp插件了 第一步，在weiphp后台管理页面创建一个插件，记得把是否需要配置项和是否需要管理列表两个选项都选为“是” 第二步，安装创建好的插件，点击插件右侧的安装链接即可 回到weiphp前台管理页面，点击左侧的留言板就能看到已经安装好的留言板插件了 3、查看代码结构 插件创建成功后，weiphp框架会自动在Addons目录下生成一个插件文件夹，本教程生成一个liuyanban文件夹，liuyanban目录下包 括Controller、Model、View三个文件夹和config.php、LiuyanbanAddon.class.php两个文件。 Controller里面一般写逻辑处理代码，包括数据插入、数据查询等功能代码，Model里面主要写一些与微信交互的代码，View里面放前台模板。 config.php是配置文件，LiuyanbanAddon.class.php是插件信息文件，一般不需要修改。 4、测试插件是否可用