参考资料
正文
最近的工作又回到了微信公众号开发（创业团队摸石头，什么都得干。。。），在办公室的电脑上搞了台测试服务器，代码库放在办公室另一台电脑上。方便起见，打算给产品服务器做一个 push-to-deploy 。
所有自己搭建过 git 服务器的人应该都知道，服务器的 git 仓库一般都是 bare 仓库，没有工作目录。而如果不创建成 bare 仓库的话，对当前 branch 的 push 操作都会被拒绝。
以前做 push-to-deploy 的方式是使用 git 的钩子执行脚本，在收到 push 后临时设置仓库的工作目录，检出代码，然后再清除工作目录。虽然也没什么障碍，但总觉得有些不爽就是了。幸运的是，这种额外的配置在 git 2.3 以后就不再是必须的了。
Git 2.3 引入的新特性
Git 2.3 版本以后，如果你向服务器上有工作目录的仓库 push 改动的话，只要服务器的工作目录是干净的（没有未提交的变更），你 push 的改动就会直接体现在服务器的工作目录下。不需要编写钩子脚本，要实现 push-to-deploy 只需要在服务器的仓库改动一个设置就完事了：
$ git config receive.denyCurrentBranch updateInstead话说这个配置的命令还真是有够直白，好像都没必要特意去记下它了。。。
配置流程
以上，猴子都能懂的 push-to-deploy 攻略总结如下：
服务器更新 Git 版本到 2.3 以上（建议 2.4 以上，后文解释）
服务器在选定的网站根目录新建 Git 仓库，不用 bare 。
服务器在新建的仓库下执行命令：
$ git config receive.denyCurrentBranch updateInstead客户端 Git 版本随意，在新仓库或原有仓库中新建一个名为 deploy 的 remote repo ，指向服务器仓库地址：
git remote add deploy ssh://gaga@foo.bar/path/to/your/document/root客户端向 deploy 分支 push 变更，服务器端工作目录随即改变。
完事
另外一些可能有用的东西
Git 2.4 对这个特性又做了一些补充，加入了一个仅在该特性被触发时会执行的钩子
push-to-checkout。对于一些代码更新后需要额外进行一些操作的项目，这是一个十分贴心的小功能。其他更新详见参考资料 2 。这种方式会在项目根目录暴露包含项目所有历史的 .git 文件夹，如果项目对此比较敏感的话最好谨慎处理。
