1. 基于Github的pull request流程做开源贡献

    最近给 beego 提了几个 pull request (简称PR),都已被接受。在使用pull request的过程中,遇到了一点小问题,才知以前并非真的理解这个流程,故在此做点记录整理。

    我以 beego 为例,将pull request的整体使用流程绘图如下:

    fork-pull-request

    beego代码库有两个长期分支 masterdevelopmaster为稳定分支,develop为开发分支,所有PR都要求提交到 develop 分支。

    1. 先将 astaxie/beego 代码库 fork 一份到自己的名下(如我的 youngsterxyf/beego)。
    2. youngsterxyf/beego clone 到本地机器上做开发。因为PR要提到 astaxie/beego 的 develop 分支,所以最好对应地在你fork的代码库的 develop ...
    Tagged as : github 笔记 git 开源
  2. 运营开发规范化

    今年3月底毕业,入职腾讯做运营开发,至今6个月有余。入职之时组内仅有1个运营开发的同事,到目前已扩充到5人,加3个实习生。

    入职之时的运营开发过程是这样的:

    1. 在办公机器(Windows)上编写代码,功能测试通过后,
    2. ssh远程连接到生产服务器(Linux),vim打开一个新文件,复制办公机器上的代码,粘贴到vim中,保存,
    3. 打开浏览器测试上线的功能/效果是否正确,若不正确,
    4. 直接在生产服务器上编辑代码文件,直到达到需要的功能效果,
    5. 再从生产服务器上将修改后的代码复制粘贴到办公机器(也许不会有这一步,之后所有的修改都直接在生产服务器上操作)。

    这个过程存在如下问题:

    1. 代码没有版本控制
    2. 没有与生产服务器一致的测试环境
    3. 代码部署过程繁琐
    4. 办公开发机器上代码很可能比生产服务器上代码还旧
    5. 上面4点都会导致混乱

    除此之外,当团队从1人扩充到多人后,不可避免地会遇到协作的问题,解决代码开发协作问题一般涉及如下几方面:

    1. 使用代码版本控制
    2. 规定版本控制的工作流
    3. 编码规范
    4. 项目/代码文档
    5. 定期code review

    为了解决上述问题,我陆续地做了如下工作:

    搭建Gitlab服务器、测试服务器

    个人认为开发工作规范化的第一点就是版本控制,基于版本控制可以完成很多自动化的任务。

    平时个人的代码、文档都通过Git版本控制存放在Github上 ...

  3. 通过示例学习Git内部构造(译)

    原文:Learning Git Internals by Example

    译者:youngsterxyf


    状态:草稿

    计划修订本文,未来可能会简化一些...

    动机

    从Subversion和Mercurial切换到Git之后的几个月,我始终觉得Git在本质上是不同于Subversion和Mercurial的,但没法确切地说出区别。 我经常在Github上看到tree、parent等术语,也搞不清楚它们确切的含义。

    因此我决定花些时间学学Git。

    我会尝试概述,并阐述一路走来学到的关于Git的关键信息...但这仅是有助于我回答Git与其他源码控制工具区别的Git内部构造基本知识。

    实体、引用、索引(Objects,References,The Index)

    要理解Git内部构造的核心,我们应理解三个东西: 实体引用索引

    我发现这个模型非常优雅。用一个小小的图表就能完全展现,也易于理解记忆。

    Big Picture

    实体

    你提交到一个Git代码仓库中的所有文件,包括每个提交的说明信息(the commit info)都在目录 .git/objects/中存储为实体

    一个实体以一个40字符长度的字符串 ...

    Tagged as : Git 翻译
  4. FTP是90年代的,使用Git取代它来部署代码吧!(译)

    原文:FTP is so 90's. Let's deploy via Git instead!

    译者:youngsterxyf

    首先,在你的服务器上创建一个目录,并在其中初始化一个空的git仓库。我喜欢使用~/www/目录来存放网站代码, 因此我会这么做:

    mkdir ~/www/example.com && cd ~/www/example.com
    git init
    

    接着,设置你服务器上的git仓库以便很好地通过git push来部署代码。

    git config core.worktree ~/www/example.com
    git config receive.denycurrentbranch ignore
    

    最后,为git设置一个post-receive钩子来检出 ...

    Tagged as : Git 翻译
  5. 搭建测试服务器(源码编译方式)

    目前工作中开发流程还比较初级,甚至连测试服务器都没有,代码的变更都是直接先在开发人员的本地机器上简单测试一下,然后直接部署到生产服务器上,这就相当于生产服务器同时充当了测试服务器的角色,虽然开发的是面向公司内部的系统,但作为一个有理想有追求的码农,是不允许这样粗糙混乱的开发流程的,所以申请了台服务器,自己搭建个测试服务器。

    由于公司的服务器统一使用SUSE Linux Server操作系统,并且版本较老。与Ubuntu、Centos等Linux发行版不同,SUSE Linux没有可用的软件源(不知是否与OpenSUSE的软件源兼容?),即没法使用系统的软件包管理工具。这样问题就很多了。

    我选择源码编译的方式来安装所有涉及的软件。也许有人会说,为什么不在网络上查找RPM包然后安装呢?那么先想一下RPM包本质上是个什么东西呢?RPM包(以及DEB包)其实就是将编译好的一些程序以一定的规则打包在一起,然后系统的包管理工具(yum、zypper)按照相同的规则(在依赖满足的情况下)将RPM包里文件复制到指定好的目录里。如果RPM包的依赖没有解决,是无法成功安装的。即使安装好了,若程序依赖的动态链接库等不存在或版本不匹配,也是无法正确运行的,比如libc库的版本过低,但明显你不能轻易替换libc库,因为系统中已安装的很多程序都依赖于libc库。那么相比源码编译方式,RPM包方式的问题更难解决。

    需要安装的软件有Nginx、PHP、MySQL、Memcached、Redis、Mongodb ...

Page 1 / 1