linux成长路[三]——搭建VPN

VPN有什么用

用处就多了,不过主流就是用来翻墙。

VPN的搭建步骤

注:我也是看人家的文章的,原文《Debian下shadowsocks-libev一键安装脚本》

本脚本适用环境:
系统支持:Debian/Ubuntu
内存要求:≥128M
日期:2016 年 11 月 05 日

关于本脚本:
Debian 或 Ubuntu 下一键安装 libev 版的 shadowsocks 最新版本。该版本的特点是内存占用小(600k左右),使用 libev 和 C 编写,低 CPU 消耗,甚至可以安装在基于 OpenWRT 的路由器上。
友情提示:如果你有问题,请先参考这篇《Shadowsocks Troubleshooting》后再问。

默认配置:
服务器端口:自己设定(如不设定,默认为 8989)
客户端端口:1080
密码:自己设定(如不设定,默认为teddysun.com)

使用方法:
使用root用户登录,运行以下命令:

wget --no-check-certificate https://raw.githubusercontent.com/teddysun/shadowsocks_install/master/shadowsocks-libev-debian.sh

chmod +x shadowsocks-libev-debian.sh

./shadowsocks-libev-debian.sh 2>&1 | tee shadowsocks-libev-debian.log

安装完成后,脚本提示如下:

Congratulations, Shadowsocks-libev install completed!
Your Server IP:your_server_ip
Your Server Port:your_server_port
Your Password:your_password
Your Local IP:127.0.0.1
Your Local Port:1080
Your Encryption Method:aes-256-cfb

Welcome to visit:https://teddysun.com/358.html
Enjoy it!

卸载方法:
使用 root 用户登录,运行以下命令:

./shadowsocks-libev-debian.sh uninstall

使用命令:
启动:/etc/init.d/shadowsocks start
停止:/etc/init.d/shadowsocks stop
重启:/etc/init.d/shadowsocks restart
查看状态:/etc/init.d/shadowsocks status

客户端使用:

再次强调,原文出处《Debian下shadowsocks-libev一键安装脚本》


linux成长路[二]——购买VPS

什么是VPS

VPS(Virtual Private Server 虚拟专用服务器)技术,将一台服务器分割成多个虚拟专享服务器的优质服务。

为什么选择VPS

便宜

如何选择VPS

一般情况下,大家都会选择海外的VPS,原因有三:

  1. 能够搭建vpn(翻墙)
  2. 便宜
  3. 不用备案

海外有不少知名的VPS提供商,如linode、搬瓦工等。最开始我是选择linode的,后来经同事推荐转去了价格低廉许多的budgetVM,然而用了一段时间后发现延迟非常大,已经到达了影响正常使用的地步,最后无奈又换了一家提供香港VPS的服务商(之前linode和budgetVM都是选择美国地区的,并不是说远岸的都那么坑,只是能否买到一台好机得看人品)。换了香港VPS后用着还是挺顺手的,延迟从190+ms直接降到60+ms,当然价格也不再那么实惠了。值得一提的是购买香港VPS一定要选择cn2网络的,至于我用着的是哪家服务商在这里就不打广告了。

如何选择操作系统

VPS一般都不会有非常高的性能,所以Windows Server就不用考虑了,没特殊情况大家都选择Linux。
Linux有多个版本,主流的有CentOS、Redhat、Ubuntu、Debian等等,我选择的是Debian,原因是最开始我对这些版本的认识是一片空白,当时同事选的Debian所以我也就跟着用了,用到现在感觉也不错,对于Debian的常见疑问网上还是挺多解决答案的。


Git实战教程[六]——基于GitLab搭建Git服务器

安装步骤(bitnami方式)

  1. 下载GitLab

    $ wget https://downloads.bitnami.com/files/stacks/gitlab/8.14.3-0/bitnami-gitlab-8.14.3-0-linux-x64-installer.run
  2. 运行安装包

    $ chmod  777   bitnami-gitlab-8.14.3-0-linux-x64-installer.run
    $ ./bitnami-gitlab-8.14.3-0-linux-x64-installer.run

    安装过程中需要输入邮箱、账号、密码、绑定域名等信息

  3. 赋权

    $ chown -R root:gitlab_ci /home/gitlab_ci  
  4. 安装成功后通过安装过程中填写的域名绑定即可访问

使用简介

  • 通过安装时输入的域名访问GitLab
    QQ截图20170118151004.png

  • 创建项目
    QQ截图20170118151841.png

  • 项目创建后可在项目详情查看项目的文件、分支、标签等信息
    QQ截图20170118152145.png

  • 进入项目的分支详情可以创建新分支
    QQ截图20170118155750_副本.png

  • 在项目详情的设置中选择Protected Branches可进行项目分支的权限设置
    QQ截图20170118155735_副本.png
    QQ截图20170118154648.png


[目录]
[上一篇] Git实战教程[五]——发布操作



Git实战教程[附录一]——分支模型设计

前言

本教程中的分支模型是从Git经典模型中按实际开发需要修改而得。

Git模型

gitdashflow.png

当前模型

current

比较

当前模型比Git模型仅仅少了release分支,因为我们的项目基本都是覆盖发布,很少出现多版本共同存在的情况,为减少发布的操作所以取消了release分支。相应的若项目需要实现多版本共存则可以通过增加release分支实现。

再谈Git分支

Git可以通过分支实现非常灵活的版本管控,很多情况下都可以通过增加分支解决版本问题。
最开始学习Git的时候为了尽量保持分支的简单易懂(分支越多,操作越多),远程仓库只有master和dev分支,但是在热修复的情况下developer角色没有权限把fix bug分支的内容直接提交到master分支,在最后不得不加上hotfix分支作为中间分支解决热修复的问题(《Git实战教程[四]——Bug热修复》)。经过这一演进过程,一方面感受到Git分支概念的灵活强大,另一方面不得不佩服Git模型的实用性(目前很多组织认为Git模型过于繁杂,纷纷对其改造,如GitHub的workflow则非常简化,但是对于传统型项目始终是Git模型更能胜任)。


[目录]



Git实战教程[二]——环境搭建

一、安装TortoiseGit

TortoiseGit下载地址
安装过程略。

二、安装Git

Git For Windows
安装过程略

三、TortoiseGit配置Git

TortoiseGit只是相当于一个图形界面,底层还是要调用Git的命令行,所以TortoiseGit要配置Git的路径。

  • 右键TortoiseGit -> Settings
    aa_副本.png

  • 在General标签中配置Git.exe的目录
    QQ截图20170110173116_副本.png


[目录]
[上一篇] Git实战教程[一]——Git基础
[下一篇] Git实战教程[三]——本地开发



Git实战教程[五]——发布操作

操作流程图如下

QQ截图20170116145023_副本.png

1.把dev分支的内容push到master(操作前需确保dev分支上内容已是最新)

2.switch 切换到master分支

3.执行merge操作,合并来自dev分支push的内容

QQ截图20170110151355.png

4.右键项目TortoiseGit -> Create Tag,新增一个名为v1.0.0的标签

QQ截图20170116134258_副本.png

5.提交Tag到远程仓库

步骤四中创建的标签,只在本地生效,需提交到远程仓库才能创建永久标签。TortoiseGit -> Push, 在弹出窗口注意选择Include Tags,然后点OK。
QQ截图20170116134554_副本.png

6.更新hotfix分支保持与master一致

注:这一步留在待发现bug时再更新hotfix分支也可以,看团队选择。

  • 从master分支push到hotfix分支
  • hotfix合并从 master push 过来的内容

做完以上步骤,就可以打包发布了~


[目录]
[上一篇] Git实战教程[四]——Bug热修复
[下一篇] Git实战教程[六]——基于GitLab搭建Git服务器



Git实战教程[一]——Git概述

前言

本教程针对实战操作,一切内容从实操角度出发,对底层命令的使用和过深的概念不作阐述。本教程主要基于TortoiseGit等图形界面工具的使用进行讲解,但是操作是互通的,理解了概念后换成任一工具都可以。建议在了解应用层面后也了解一下Git的底层操作,可参考Git经典教程《Git教程——廖雪峰的官方网站》

什么是Git

一个版本控制系统,特点是免费、开源、高效、分布式。

Git与SVN

  • Git相对SVN的优点
    Git的优势在于能够非常灵活的基于指针创建分支,提高项目版本的灵活性。SVN是基于文件复制创建分支,导致分支功能效率低下、非常鸡肋,所以SVN的开发操作一般都在主线上,版本管理相对限制。
  • SVN相对Git的优点
    SVN天生就是集中式版本管理系统,对权限控制的支持达到极致,可以根据项目组要求进行文件级别的各种权限限制;Git倡导的是开源精神,所以Git对权限管理的支持不高,虽然可以通过例如GitLab等服务配置权限,但也只能配置控制到分支级别。

Git的重要概念

  • Git的分布式与集中式
    Git是基于分布式的版本管理系统,主要的思想是去中心化,意思是所有的机子都可以成为远程仓库,理论上是每个人都可以从最近的机子获取代码。但是Git的实际应用中主要还是基于集中式进行,通常会有一台服务器作为远程仓库,项目组的开发成员会从这个远程仓库上获取代码,而最后也是提交代码到这个远程仓库。

  • Git的本地仓库与远程仓库
    Git中会有本地仓库和远程仓库的概念,在这里我们简单的把本地仓库当作开发者的本地Git,而远程仓库就是上边提到的集中式的中心仓库,本地仓库要向远程仓库提交代码时是通过push操作实现的。
    补充:为什么只能是本地仓库向远程仓库(此处特指中心仓库)push,而不能反过来?Git是分布式的,理论上每个仓库都是平等一致的,中心仓库其实也是一个普通仓库。假设仓库A向另一个仓库B push文件时,建立的连接是基于ssh的,那么前提就要求仓库B必须保存了仓库A的SSH key,也就是仓库A要先创建SSH key,然后把SSH Key告诉了仓库B,在仓库B保存了仓库A的SSH key后A仓库才有权限把文件push到仓库B,基于这个原理我们就能够轻易的实现集中式的Git。

  • Git的分支
    Git的最强大之处就是以分支为主导的开发模式,本教程中是比较精简的模型,远程仓库主要有master和dev两条分支,为了实现热修复还有一条hotfix分支。开发的时候开发者需要习惯为每个开发任务分别创建分支,在新的分支上进行功能开发,开发完成后再合并到远程分支。

Master和Developer角色

本例中设定的角色只有Master和Developer角色。一般开发者都是Developer角色,拥有对dev、hotfix分支的所有权限,但不能操作master分支;而能够拥有版本发布权限的开发者则是Master角色,除了拥有dev分支的所有权限外,还拥有master分支的所有权限。

Git的常用功能

  • clone 从远程仓库下载项目到本地
  • pull 更新本地文件
  • create branch 创建分支
  • switch/checkout 切换分支
  • commit 修改内容提交到分支
  • push 把分支内容提交到远程仓库
  • merge 合并从其他分支push过来的内容
  • stash save 保存当前工作快照
  • stash pop 恢复工作快照

分支模型

QQ截图20170113131952_副本.png

分支模型的设计可参考《Git实战教程[附录一]——分支模型设计》


[目录]
[下一篇] Git实战教程[二]——环境搭建



Git实战教程[目录]
Git实战教程[四]——BUG热修复

此处的“BUG热修复”指的是不影响dev分支的情况下修复master主线上某一版本的BUG。

假设场景

  1. 项目在半个月前发布了1.0.0版本,并在master主线上打了一个名为1.0.0的TAG;
  2. 客户今天突然发现了生产环境上一个严重的BUG,接到投诉的项目经理要求对问题紧急修复,并尽快发布;
  3. 项目的代码相对1.0.0版本已经是面目全非的状态;
  4. 你已经阅读过《Git实战教程[二]——本地开发》

操作流程图如下

QQ截图20170116233331_副本.png

1. Stash保存工作镜像

  • TortoiseGit -> Stash Save
    QQ截图20170116214333.png
  • 在弹出的窗口填写镜像信息,方便之后还原
    QQ截图20170116214644.png

    2. 基于tag v1.0.0创建fix bug分支

    右键项目 TortoiseGit -> Create Branch,在弹出窗口中填写分支名称,并选择Base On Tag v1.0.0。
    QQ截图20170116133625.png

3. 修复Bug

  • 在fix bug分支上修复bug
  • 修复后提交修改到本地仓库
  • push代码到hotfix分支

    4. 更新hotfix分支

  • hotfix合并fix bug分支push的内容(Merge时注意选择from Branch remotes/origin/hotfix),待测试人员测试

    5. 更新dev分支

    注:hotfix测试通过后master分支的发布将由Master角色的人员负责,而developer虽然不用处理master分支,但是仍然要把fix bug分支的内容提交到dev分支,否则下次发布版本时bug依然存在。
  • 从dev分支pull,更新hotfix代码
    QQ截图20170116230220.png
  • 在假定场景中提到v1.0.0与dev相差很大,所以pull后出现冲突是非常正常的。
    QQ截图20170116230650.png
  • 对于冲突的地方应按提示进行修改,解决冲突。
    QQ截图20170116230704.png
  • 解决完冲突后fix bug分支push代码到dev分支,然后再merger dev分支即可。

    6. Stash Pop还原工作镜像

  • TortoiseGit -> Stash Pop 还原成上一次Stash保存的工作镜像。
    (若有多个stash镜像可通过TortoiseGit -> Stash List查看镜像列表,然后指定一个镜像进行还原)

[目录]
[上一篇] Git实战教程[三]——本地开发
[下一篇] Git实战教程[五]——发布操作



Git实战教程[三]——本地开发

操作流程图如下

QQ截图20170116131233_副本.png

1. Clone项目

  • 切换到项目本地待存放目录,右键菜单选择Git Clone
    1.png

  • 在弹出窗口填写项目git地址,点击OK
    2.png

2. 切换到dev分支

  • 选中项目右键菜单选择Switch/Checkout项
    3.png

  • 选择dev分支(若本地没切换过dev分支则只能选择remotes/origin/dev分支)
    4.png

  • 右键项目,选择pull,更新项目到当前分支最新状态
    5.png

3. 本地开发新功能

  • 创建新分支(建议每当进行一个新的开发任务时都创建一个分支),右键项目选择Create Branch
    6.png

  • 在弹出窗口中填写分支名称,注意Base On是dev分支,勾选Switch to new branch,点击OK,然后就可以在新创建的分支下进行功能开发。
    7.png

4. 提交代码

  • 右键项目,选择Commit,把本地修改提交到新功能开发分支
    8.png

  • 填写更改信息,点击OK
    9.png

  • 右键项目TortoiseGit->Push,在弹出窗口选择从新功能开发分支推送到dev分支,点击OK
    10.png

5.更新dev分支代码

  • TortoiseGit->Merge,在弹出窗口选择remotes/orign/dev分支,点击OK。
    11.png

完。


[目录]
[上一篇] Git实战教程[二]——环境搭建
[下一篇] Git实战教程[四]——Bug热修复