sofish 来了。我围观下。

那么多得回复，看不完，不过这个帖子就是看回复的。

不知道什么鬼了。

中介知道房主的最低价格。多出部分给提成，如果提成低于小费，那肯定是给房主接受的最低价格，拿最高收益。 从《魔鬼经济学》学到的。

15 楼说得对。照着用就行。

满满的 bootstrap 风格。

感觉比国内的好。

收藏了。

看了下，没我的 ip ，放心了。

亿元规模的 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'

有我喜欢的珠江。

有我爱的家人。

不像冷清的北京。