数据与智能

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

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

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

1. 先将 astaxie/beego 代码库 fork 一份到自己的名下（如我的 youngsterxyf/beego）。
2. 把 youngsterxyf/beego clone 到本地机器上做开发。因为PR要提到 astaxie/beego 的 develop 分支，所以最好对应地在你fork的代码库的 develop …

今年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上 …

原文：Learning Git Internals by Example

译者：youngsterxyf

状态：草稿

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

动机

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

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

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

实体、引用、索引（Objects，References，The Index）

要理解Git内部构造的核心，我们应理解三个东西： 实体、引用、 索引。

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

实体

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

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

原文：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钩子来检出master分支 …

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

由于公司的服务器统一使用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 …

今天因为某些尚不明了的问题导致，博客的Git pages始终构建失败，于是想在远程版本库中删除前几次提交。在该网页上找到了解决方案：

git reset --hard HEAD~2                   # 取消当前版本之前的两次提交
git push origin HEAD --force              # 强制提交到远程版本库，从而删除之前的两次提交数据