Geralmente, existem duas maneiras de gerenciar esse tipo de problema:
-
Você tem um repositório nu centralizando seu aplicativo em algum lugar no servidor e um clone desse repositório (com uma árvore de trabalho) em cada pasta
httpdocs
você define um
post-receive hook
no repositório nu para atualizar todos os cloneshttpdocs
deste repositório, normalmente um script de shell será suficiente (e pode configurar permissões e fazer% globalchmod
com base em seus usuários)E você tem outra cópia do repositório em uma máquina local que envia para este repositório
bare
no servidor, que aciona os ganchos pós-recebimento e atualiza todos os repositórios "filhos" em seus diretórioshttpdocs
-
Você obtém a parte
.git
dehttpdocs
(que eu recomendo) e configura os repositórios na pasta/private/home/git/myrepo
(crie-a) comworking tree
inhttpdocs
$ git --git-dir=/var/www/vhosts/newdomain.tld/private/home/git/newdomain.tld \ --work-tree=/var/www/vhosts/newdomain.tld/httpdocs init && \ echo "gitdir: /var/www/vhosts/newdomain.tld/private/home/git/newdomain.tld" \ > /var/www/vhosts/newdomain.tld/httpdocs/.git
Dessa forma, seu
httpdocs
permanece relativamente limpo de informações de versão (exceto o.git
FILE (não dir) criado em/var/www/vhosts/newdomain.tld/httpdocs/
, que é apenas uma maneira do GIT de criar links simbólicos paraworking tree
com a localização doGITDIR
)o restante do procedimento é o mesmo: repositório bare, ganchos pós-recebimento
Eu pessoalmente desisti de Gitosis, gitolite & palls, porque é muita sobrecarga para apenas alguns repositórios. Configurar corretamente suas ramificações remotas e um script de shell é tudo o que é necessário (lançado pelo gancho pós-recebimento)
Mais sobre hook
no githooks (5) página de manual