说一下我厂之前一个工程的部署方式吧。
项目结构：
该工程下面 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/ 贴下链接。