代码管理

一.拉取最新代码 　　一般在本地进行开发时,都是切换到自己的dev分支进行开发,当开发完成需要进行代码提交,在进行代码提交前需要先进行拉取远程仓库代码,进行更新,但是此时会提示需要将本地代码进行commit或者stash,一种解决办法如下: 　　在自己的dev分支执行 git stash 将所有的更新进行暂存, 然后执行git pull 从自己的远程仓库拉取一下代码 　　切换到developer分支进行git pull 从项目的远程仓库拉取最新的代码 　　切换到自己的dev分支 执行git rebase developer 将刚才从项目的远程仓库拉取到本地的代码合并到自己的dev分支, 一般这时候都不会产生冲突(因为已经将自己的修改进行了暂存) 二.将暂存区弹出, 还原需要进行修改的代码 　　git stash list 可以查看暂存区各个文件的序列号 　　git stash pop 将暂存区所有的文件弹出 　　git stash pop 序列号　　按照序列号将暂存区的文件弹出 三.解决冲突 　　将暂存区的文件弹出合并后,如果存在冲突, git 会把冲突文件的路径显示出来,找到并打开文件,处理冲突(文件合并时,同一处代码,出现异同) 　　<<<<<<<<<<<< update up stream 　　　　a = int("3") 　　============ 　　　　a = int

今年疫情的严重程度似乎超出了所有人的预想，随着国家法定的假日即将结束，大家返回工作地的风险依然存在，即使已经返回了工作地，现在所有人返回公司集中工作都不是明智之选，通过远程办公来降低公司生产力损失看起来很有必要，远程办公会有哪些可能的损失和降低的方法呢？今天我们主要围绕软件研发团队的远程办公的几个问题聊一聊。 目标驱动 VS 熬时间 提到远程办公，大家首先可能想到的就是工作时间不可控，团队成员的产出不可控怎么办？ 目标牵引，对于软件行业的脑力工作者，即使在公司工作，员工到底在干什么也是无法知道的，在远程办公的情况下更是如此，我们可以通过更明确、更细粒度的目标牵引来解决。目标建议拆分到每天的粒度，并且要有明确的是否达成，同时通过进展的透明来促进大家达成每日承诺，在目标拆解与进展透明章节会再讲讲这个问题。 目标牵引并不是完全不强调工作时间，沟通在软件开发中已经越来越重要，为了保障沟通的效率，团队成员还是要有一个明确的工作时间，通常可以参考公司正常的上班时间即可，可以和员工强调工作时间需要在线，确保其他成员需要沟通时能够随时进行。 代码云托管 VS 代码内网无法访问 开发人员远程办公需要解决的另一个问题就是环境，如果你的公司必须在内网环境开发，又无法提供远程或者VPN能力，那远程办公基本是不可能的了。但大部分公司的开发人员只要有一台电脑，基本都能够进行开发工作了

一、git的工作原理 git是分布式管理系统，每个开发者的本地就是一个代码管理仓库，开发者本地分为三个区，分别是工作区、暂存区、历史区 工作区：我们能看到的，用来写代码的区域 暂存区：临时存储 历史区：生成历史版本 二、git的全局配置 第一次安装git后，需要在全局环境下配置基本信息：我是谁？ $ git config -l //查看配置信息 $ git config --global -l //查看全局配置信息 //下面配置用户名和邮箱 $ git config --global user.name 'XXX' $ git config --global user.email 'XXX@xxx' 三、创建仓库完成版本控制 创建本地git仓库 $ git init //会生成一个隐藏文件夹 '.git'，这个文件夹不能删除，因为暂存区和历史区还有一些其它信息都在这里存放 本地编写代码后（在工作区），把这些文件提交到暂存区 $ git add [filename] //提交某一个文件 $ git add . //提交本地所有修改的文件 $ git status //查看当前文件的状态（红色代码在工作区，绿色代码在暂存区，看不见东西证明所有修改的新信息都已经提交到历史区） 把暂存区内容提交到历史区 $ git commit -m '提交的描述信息' $ git log /

一、持续集成概念理解 白话理解：多个开发人员多次将自己写的提交代码到某个文件夹,通过又之前的代码进行整合,发现错误并修改; 持续集成(Continuous integration,简称CI),简单地说就是多个开发人员一天多次地将自己编码的代码提交到主干; 01:快速定位错误(每完成一点代码更新,就提交到主干,通过以之前提交的代码进行集成可以快速发现其中的错误) 02:防止分支大幅度偏离主干(若不经常持续集成,主干又在不断更新,会导致以后集成的难度变大,甚至难以集成); 持续集成的目的就是让产品可以快速迭代,同时还能保持代码的高质量。 二、持续交付概念理解 白话理解：所有开发人员在某个时间代码提交完成后,交给质量团队(测试工程师)进行测试。 持续交付(Continous delivery)指的是,频繁地将软件的新版本,交付给质量团队(测试人员)或者用户,以供评审,如果 评审通过,代码就进入生产阶段。持续交付可以看作是"持续集成"的下一步。它强调的是，不管代码怎样更新，软件 是随时随地可以交付给质量团队(测试人员)和用户进行评审。 三、持续部署概念理解 白话理解：质量团队(测试工程师)测试代码没问题,将代码交给运维人员,运维人员通过工具将代码发布到生产服务器 持续部署(Continuous deployment)是就是"持续交付"的下一步,指的是代码通过评审后,可以自己的部署到生产环境

https://mp.weixin.qq.com/s/tHRl5OQHY2mNXqKwACCVWw?utm_source=tuicool&utm_medium=referral 一、架构的三个维度和六个层面 1.1、三大架构 在互联网时代，要做好一个合格的云架构师，需要熟悉三大架构。 第一个是IT架构，其实就是计算，网络，存储。这是云架构师的基本功，也是最传统的云架构师应该首先掌握的部分，良好设计的IT架构，可以降低CAPEX和OPEX，减轻运维的负担。数据中心，虚拟化，云平台，容器平台都属于IT架构的范畴。 第二个是应用架构，随着应用从传统应用向互联网应用转型，仅仅搞定资源层面的弹性还不够，常常会出现创建了大批机器，仍然撑不住高并发流量。因而基于微服务的互联网架构，越来越成为云架构师所必需的技能。良好设计的应用架构，可以实现快速迭代和高并发。数据库，缓存，消息队列等PaaS，以及基于SpringCloud和Dubbo的微服务框架，都属于应用架构的范畴。 第三个是数据架构，数据成为人工智能时代的核心资产，在做互联网化转型的同时，往往进行的也是数字化转型，并有战略的进行数据收集，这就需要云架构师同时又大数据思维。有意识的建设统一的数据平台，并给予数据进行数字化运营。搜索引擎，Hadoop，Spark，人工智能都属于数据架构的范畴。 1.2、六个层面 上面的三个维度是从人的角度出发的

本文由 网易云 发布。 作者：刘超，网易云首席解决方案架构师 最近总在思考，为什么在支撑容器平台和微服务的竞争中，Kubernetes 会取得最终的胜出，事实上从很多角度出发三大容器平台从功能方面来看，最后简直是一摸一样。（可参考 《容器平台选型的十大模式：Docker、DC/OS、K8S 谁与当先？》 ） 经过一段时间的思索，以及采访了从早期就开始实践 Kubernetes 的 网易云 架构师们后，我把反思所得总结为今天的这篇文章。 一、从企业上云的三大架构看容器平台的三种视角 如图所示，企业上云的三大架构为 IT 架构、应用架构和数据架构，在不同的公司，不同的人、不同的角色，关注的重点不同。 对大部分的企业来讲，上云的诉求是从 IT 部门发起的，发起人往往是运维部门，他们关注计算、网络、存储，试图通过云计算服务来减轻 CAPEX 和 OPEX。 有的公司有 ToC 的业务，因而累积了大量的用户数据，公司的运营需要通过这部分数据进行大数据分析和数字化运营，因而在这些企业里面往往还需要关注数据架构。 从事互联网应用的企业，往往首先关注的是应用架构，是否能够满足终端客户的需求，带给客户良好的用户体验。业务量上往往会有短期内出现爆炸式增长的现象，因而关注高并发应用架构，并希望这个架构可以快速迭代，从而抢占风口。 在容器出现之前，这三种架构往往通过虚拟机云平台的方式解决。当容器出现之后

Spring学习笔记（一） 一、Spring 框架 Spring 是一个开源框架，是为了解决企业应用程序开发复杂性而创建的。框架的主要优势之一就是其分层架构，分层架构允许您选择使用哪一个组件，同时为 J2EE 应用程序开发提供集成的框架。 Spring框架由 七个模块 组成:核心容器、应用上下文（Context）模块、Spring的AOP模块、JDBC抽象和DAO模块、对象/关系映射集成模块、Spring的Web模块、Spring的MVC框架。 介绍传送门--> http://baike.baidu.com/link?url=ZMgPopo8CSuxoq4cxxCjy600WLc07HP9K4ej4wI4Z07jpfyt82RlOk1MimelYU_tZwn9OyLE_dQVlXNzDm_Fba 、 二、关于学习Spring框架之前自身的疑惑 1 Spring框架是如何对项目进行有效管理的? 三、学习开始 3.1 准备好Spring的说明书 http://docs.spring.io/spring/docs/ 3.2 准备Spring的JAR包 spring-framework-3.0.0.RELEASE 3.3 先写一点测试代码（不使用Spring框架），然后再引入Spring框架进行管理，对比前后者代码的不同之处 测试代码逻辑: 1 UserServiceImpl调用

首先，给出上一篇内容的word下载： TFS功能说明以及使用教程.zip 下面会给出本文的Word文档下载。另：本篇仅供参考，希望能者补充。 TFS源代码管理的8大注意事项 目录 源代码管理的8大注意事项... 1 1. 使用TFS进行源代码管理... 2 2. 如果代码没放在源代码管理软件里，等于它不存在... 2 3. 要早提交，常提交，并且不要觉得麻烦... 2 4. 提交前要检查你更改了什么... 3 5. 写提交信息时一定要认真... 4 6. 使用代码审阅提高代码质量... 5 7. 一定要管理好数据库的版本... 5 8. 将必要的附属文件集成到源代码管理... 5 TFS具体使用请参考此链接： http://msdn.microsoft.com/zh-cn/library/ms181382.aspx 源代码管理软件是我们工作的必备工具，是许多开发团队的血液。那么如何更好的利用TFS进行源代码管理呢？ 1. 为什么使用TFS 2012进行源代码管理 为什么使用TFS，从源代码管理方面来说，TFS具有以下优势： l 与Visual Studio无缝结合，方便开发者进行源代码管理 l 支持代码审阅与讨论 l 支持邮件通知 l 支持Web访问与管理 l 支持工作项以及BUG等管理 l 不会上传.NET开发时生成的垃圾文件 l 自带版本合并以及比较工具。 l

一.Linux进程运行时分为用户态和内核态，用户态有其自有的内存布局，内核态有内核态的内存管理机制。进程栈的管理如图1所示。 图1 进程栈示意图 说明：1.内核栈的底端为thread_info结构体，栈顶开始为堆栈区，其中PT_SIZE为保存进程现场信息的区域。其中task变量指向进程的task_struct进程管理结构体。该结构体按ORDER分配，直接分配物理页。 2.task_struct为进程管理结构体，其中stack变量指向栈首地址。该结构体属于slab分配。 3.mm_struct用户管理进程用户态的内存空间，只用涉及用户态进程才分配该结构体，该结构体属于slab分配。 4.vm_area_struct 用户空间区管理结构体，比如管理用户栈，代码段，数据段等区域，该结构体属于slab分配。其中用户空间栈的管理在第三节讲解。 二.内核栈从何而来和如何使用 1.内核栈在其父进程调用fork时创建 图2 进程栈申请代码 说明：在龙芯2K/3A平台上该空间大小为16K;所有的进程都有自己的内核栈;0号进程（idle）的内核栈通过图3所示，其它所有进程都是调用dup_task_struct函数申请空间得到。 图3 init 进程内核栈生成代码 2.内核栈如何使用-进程工作于内核态时使用 2.1 场景1-程序运行在用户态，此时产生中断或者系统调用，用户态切换至内核态

引言 如今，软件通常会作为一种服务来交付，它们被称为网络应用程序，或软件即服务（SaaS）。12-Factor 为构建如下的 SaaS 应用提供了方法论： 使用 标准化 流程自动配置，从而使新的开发者花费最少的学习成本加入这个项目。 和操作系统之间尽可能的 划清界限 ，在各个系统中提供 最大的可移植性 。 适合 部署 在现代的 云计算平台 ，从而在服务器和系统管理方面节省资源。 将开发环境和生产环境的 差异降至最低 ，并使用 持续交付 实施敏捷开发。 可以在工具、架构和开发流程不发生明显变化的前提下实现 扩展 。 这套理论适用于任意语言和后端服务（数据库、消息队列、缓存等）开发的应用程序。 特别声明 本文转自国外一篇文章，由Adam Wiggins所著，原文地址： https://12factor.net/ 在此文基础上增加个人的理解以及部分图解。 统一源代码管理系统 一份基准代码（Codebase），多份部署（depl o y） 在类似 SVN 这样的集中式版本控制系统中， 基准代码 就是指控制系统中的这一份代码库；而在 Git 那样的分布式版本控制系统中， 基准代码 则是指最上游的那份代码库。 基准代码和应用之间总是保持一一对应的关系： 一旦有多个基准代码，就不能称为一个应用，而是一个分布式系统。分布式系统中的每一个组件都是一个应用，每一个应用可以分别使用 12-Factor