亿元规模的 A 轮投资，感觉就是虚。

说一下我厂之前一个工程的部署方式吧。

项目结构：
该工程下面 n 个 git 仓库，发布到外边的网站是该工程其中的一个单独的应用仓库。

机器环境：
内网： git 服务器。一台部署机器 A 。
外网（和内网网络，需要 vpn 连接内网）：一台生产环境机器 C （跑几个实例进行负载均衡），一台测试机 D （跑两个测试环境），数据服务器 n 个 M 。一台部署机器 B 。

SSH 管理：
B 能 SSH 到所有机器。在上面一堆 TMUX session 连接着进行监控等等。
开发 /运维只能直接连接到 A/B 部署机器。

运行方式：
nginx + django + uwsgi + supervisor (apt-get 安装的靠谱， pip 安装的自启动有问题）

部署方式：
1 、部署脚本，使用 fabric 进行编写。在 B 机器上面进行运行。
2 、部署时候， B 机器和 A 机器建立 VPN 连接，然后克隆 /更新仓库的生产分支，到 B 的代码部署临时目录。克隆完毕，进行 RSYNC （需要参数： --delete --exclude 一堆）到 C/D 不同环境的生产 /测试环境的目录。同步完毕就触发各种重启 uwsgi 等等指令。


git branch ：
理论上只有两个分支。由于部分新加入开发人员，按照其他团队旧的方式协助，可能有时候造成多几个。
dev 为主开发分支
master 为主生产分支， Protected 形式。
各种 tag 用于方便历史管理。

怎么 git 协助？
开发人员 fork 仓库，在自己的分支上（和其他人协助）开发，开发完毕，就创建 mr 合并到 dev 分支。这个 mr 只能使用 gitlab 的 Accept Merge Request 来合并，不能直接 push upstream 分支，使用 rebase 自己的分支进行冲突处理。

发布测试：
1 、 dev 是一个开发分支，每次合并了新 mr 之后都要进行测试，才能发布生产。这个第一个测试环境，为生产测试环境。
2 、开发人员每次创建 mr ，都需要进行 mr 测试。这个第二个测试环境，为 mr 测试环境。（外界分享的所有 git 协助，基本上没有这个测试方式。）

发布生产：
创建 mr 将 dev 同步到 master ，通过 fab 写好的部署脚本，发布 master 到生产环境，重启进程（重启过程注意 502 问题，因此需要多个实例）

就酱，之前写过一篇 git 协助的文章， http://blog.shenqh.com/2015/01/29/best-practices-of-git/ 贴下链接。

ie 浏览器不能直接设定 style='',而是 style.display='none'

有我喜欢的珠江。

有我爱的家人。

不像冷清的北京。

价格太低。

某迅没有 java 是个该点赞的做法。


jd 描述这么高端，那干嘛不配 mac 。

阿里 p10 的报个名字看看，是大辉吗？

@troy450409405
11 楼也有说，前端习惯是用空格。

具体空格是两个还是四个，自己选择，海龟书里面有提到。
tab 是不推荐的使用的。
DW 忘了吧， svn 也忘了吧。别提这几个词，减分。
虽然英雄莫问出处，但是用 DW 写页面的前端都不是好前端。

@troy450409405 建议使用 jshint 来检验下自己的代码规范。


https://cnodejs.org/topic/4faf5b032e8fb5bc6510b5ac

如果把你的缩进换成空格，那我这推荐。

pro ，前端，同时开两个 vagrant ，使用虚拟机同步开发环境，有时候开 pd 测试， 8g 内存勉强。要我再买一台的话，绝对上 16g 。

升级了 45 版本 chrome ，内存多了。


买的话，真不要差那几个钱

http://www.speedtest.net/my-result/4637917411

北京联通，小区宽带的速度，感觉很假。。。

赞赞赞。 666

都肉身翻墙了。

不过，看这描述，如果楼主是程序员，那就肯定是渣渣的码农。