周一（2016年8月29日）一上班就遇到问题：由于公司的测试服务器经常有账号添加和删除，权限管理比较松散，所以导致了今天的结果，部署在该机器上的git-rep被删除了，凭借我们几个三脚猫的能大概是找不出原因了，没有办法，重建。

重建git并重新上传最新的代码不是问题（幸好是git，要是svn估计有点惨哦）。问题出在这里：由于是测试服务器，基本服务器端相关的人员测试都是将代码push到git-repo, 然后由git的hook脚本自动完成至测试站点的部署；为了更清晰的管理，一般我们提交的代码都是处于开发分支上，经过测试、可发布的代码都位于master分支（没错，就是master分支）。我想对git熟悉朋友知道，新建repo后默认的分支名称就是master，从远端clone的分支也是master。

但是我们需要clone后立即切换到开发分支上，个人的开发机上容易做到，但是自动部属脚本好像有一点难办。我们修改repo的hooks目录下的post-update文件，修改内容，在update动作完成后，rm掉项目测试部属目录，然后通过clone重新部署文件，再然后cd到部署目录，checkout（加上--track选项，注意，不是trace)开发分支；最后，就是自动部属完成了。

世界没有那么美好，尤其是对于我这样的3.5脚猫来说：反复折腾了好多次，我确定post-update脚本是正常被调用的，似乎问题出在了这个脚本被调用时的运行目录上：每次从programmer的机器上push代码到git-repo后，都会提示: fatal : is not git repository ".", 意思大概是说目录"."不是一个git-repo。

奇怪？我不是cd到部署目录去了吗？并且通过pwd确定了是在正确的目录啊？我尝试过：（1）将需要执行的部署命令单独放在另一个文件中，结果其它的programmer提交时提示没有权限执行那个单独的脚本文件，我“chmod -Rf 777”好多次之后，咒骂了git好多次后，想到是否应该google下再说，于是就去google了，原来hooks脚本中的运行环境有一个称为$GIT_DIR的变量，像我们这种cd到部署目录后执行的git命令，该环境变量还是hooks脚本所在的目录， 也就是说，错误中所说的"."目录其实指的hooks目录。

简单的在hooks中将环境变量GIT_DIR设置为部署目录，it works now！

当然，问题并不是完全解决了：git-repo是由我创建的，其它的同事需要向其中push代码，问题出在push时，时不时的会闪现无法写入objects目录的问题，这个大概是hash函数新建目录没有权限的原因吧，还没有认真研究，下次再说了（这句话可以明白我为什么是3.5脚猫了）。

Git代码托管自动部属功能的务实笔记