Git开源工具Gitiles、Douban CODE、gitsh、deployinator介绍

以下为你介绍的Git开源工具都可用在Linux系统上:Gitiles(Git 仓库浏览器)、Douban CODE(豆瓣代码托管系统)、gitsh(git操作环境)、deployinator(部署工具)。

1、Gitiles(Git 仓库浏览器)

Git开源工具Gitiles、Douban CODE、gitsh、deployinator介绍

Gitiles 是一个基于 JGit 的简单 Git 仓库浏览器,其重点是简单。

2、Douban CODE(豆瓣代码托管系统)

Douban CODE 是豆瓣开发的一个基于 git 版本控制系统的协作平台。

CODE —— C: Community O: Original D: Developer E: Eldamar

目前 CODE 仅开放了一个框架,支持:

clone & push project、create project、create user。

准备环境:

MySQL、Memcached、Python >= 2.7、pip >= 1.4.1、virtualenv、git。

CODE 为每个项目设置了三个角色,分为 owner(有全部权限)、committer(有 push 和 merge 权限)、member。review 机制根据项目的不同设置了不同的规则,如产品线级别的、需要对外发布的项目,基础库等项目都需要经过严格的 review,如东西团队对 review 设置了如下规则:

尊重他人,就事论事,对事不对人,毕竟每个人都写过烂代码;

PR 中的每一个 commit log 都应该可以和代码对应,方便 review;

尽量不要发太大的 PR,以免引起 reviewer 的恐慌;

建议保证一个 PR 的粒度和专注,最好不要出现一个 PR 里又有重构又加新 feature 的情况,同样容易引起 reviewer 的恐慌;

提 PR 之前请确保在本地或测试环境一切正常;

reviewee 如果接受 reviewer 提出的修改意见,需要在修改提交以后知晓 reviewer,常见的做法可以是在 review comment 处回复(并带 commit 链接);

评论中至少出现一个 lgtm 且保证 ci 通过之后 PR 才可以被合并;(注:lgtm 即 looks good to me 的缩写)

PR 合并者与提交者不能是同一个人;

PR 需从一个特定分支(分支的名字尽量能表达代码的功能)发往上游的 master 分支;

Model 的部分,如不紧急需要unittest;

Web 的部分,如不紧急需要webtest;

PR 合并后如引起 bug 或功能异常,并经查确为此 PR 引起,提交者需请全组攻城湿喝饮料或吃冰棍(由被请者决定);

将 fork 的仓库与上游同步时,应使用 git fetch upstream && git rebase upstream/master (或 code sync -r ),而不是 git merge 或 code sync (这里code是指面向 CODE 系统的一个命令行工具),以保持清晰的提交历史,并防止覆盖他人的修改;

注意安全问题,对于 SQL 拼字符串,模版中有 |n 的,以及处理用户输入等地方都需要仔细review,更多请参考 Web 安全开发指南 

对于松散或娱乐性项目、小工具项目,并不会那么严格的 review,这也取决于 owner 自己,他可以借这个项目寻找到一位导师,来帮助他进行 review:

举一个具体的例子,例如东西团队的 Android 版本的开发,实际上最开始只是团队内部的一些成员想学习 Android 开发自发组织起来的,但一开始就找了移动组的同学来随时帮助 review。 

对于 CODE 项目本身,所有工程师都可以向 CODE 上的任意项目提 PR,也都可以是CODE 的 reviewer,同时所有工程师的代码都需要经过 review 才会被 merge 到 master 分支。

发展到现在,豆瓣的 review 基本上都是自发,很少遇到需要 review 的代码堆积的情况。代码讨论区里据说时不时会出现美女图,这可能是刺激工程师们去 review 的因素之一;另外,CODE 系统本身也有奖励机制,鼓励大家去评论别人的代码。

CODE 系统的奖励机制主要有积分和勋章这两个部分。积分的规则主要就两个:

提交的 PR 被 merge,增加 100 点积分。

提交的 PR 被评论,增加 5 点积分。

目的就是鼓励多发 PR。一般来说,小 PR 要好过大 PR,不过有时候开发任务比较紧的时候,发出比较大的 PR 也是在所难免。

勋章系统在 CODE 早期阶段就做了进去,早期的奖励规则主要跟代码提交相关,例如给开源项目发过 Patch 并被 merge 会有相应的徽章。现在 CODE 团队对勋章系统有一些新的规划:

目前希望徽章系统可以独立出来,只是一套独立的API,任何人任何产品线都可以去设置自己的奖励规则,让这种奖励变成不是一种公司行为,而是更小的行为。例如 antispam 组,可能就会有百人斩徽章,这个对于其他组可能就不是那么必要,当然如果你跨界帮助过 antispam 组,那么也有可能会获得这个徽章。 

CODE 上没有设置惩罚机制。

测试:

相比 Github,CODE 有一些非常实用的地方,比如在提交代码入库之前可以先在 CI 里面完成自动测试,reviewer 可以直接看到代码测试是通过(绿色)还是失败(红色);代码完成 merge 之后还可以通过 DAE 直接往线上部署。持续集成、自动测试、监控、部署这些都是独立系统,与 CODE 都是靠 API 来进行交互。

下载地址:https://github.com/douban/code

3、gitsh(git操作环境)

Git开源工具Gitiles、Douban CODE、gitsh、deployinator介绍

gitsh 开始一个 git 操作的 SHELL 环境,用以替代原有命令行的操作方式,例如一般 git 的操作方式是:

$ git status

$ git add -p

$ git commit

$ git push

而使用 gitsh 的操作方式是:

$ gitsh

gitsh@ status

gitsh@ add -p

gitsh@ commit

gitsh@ push

gitsh@ :exit

$

Mac 下安装:

brew tap thoughtbot/formulae

brew install gitsh

下载地址:https://github.com/thoughtbot/gitsh

4、deployinator(部署工具)

Git开源工具Gitiles、Douban CODE、gitsh、deployinator介绍

deployinator 是 Etsy 开源的一鍵部署工具,只要你点一下按钮,它所做的就是从Git中拿出东西,并把它分发下去,仅此而已。

安装:

本演示假定您使用捆绑程序安装deployinator。如果不是,则可以跳过捆绑程序步骤。

为项目创建一个目录,以保存您的特定代码(在gem之外,这将是您自己的内部存储库)。mkdir test_stacks。

为捆绑程序创建一个Gemfile:

source 'https://rubygems.org'

gem 'etsy-deployinator', :git => 'https://github.com/etsy/deployinator.git', :branch => 'master', :require => 'deployinator'

使用捆绑程序安装所有必需的gem:

$ bundle install --path vendor/bundle

运行以下命令以使您可以使用deployinator gem的rake任务:

$ shopt -s xpg_echo

$ echo "require 'deployinator'\nload 'deployinator/tasks/initialize.rake' " > Rakefile

为部署日志尾部后端创建一个binstub:

bundle binstub etsy-deployinator

通过运行以下命令将Company替换为公司/组织的名称来初始化项目目录。这必须以大写字母开头:

$ bundle exec rake 'deployinator:init[Company]'

将tailer作为后台服务运行(使用您喜欢的任何初始化样式):

./bin/deployinator-tailer.rb &

下载地址:https://github.com/etsy/deployinator

注明

以上就是Git开源工具Gitiles、Douban CODE、gitsh、deployinator的介绍内容,这些Git开源工具都能使用在Linux操作系统中。

栏目相关文章