Git: tornando seguros os repositórios não-bare

Eu poderia usar algumas orientações dos especialistas em git por aí sobre como tornar seguras as operações push para repositórios não-nua. Basicamente, tenho um plano sobre como fazer isso e poderia usar alguns conselhos sobre se o plano é sensato ou não:)

Normalmente, quando você envia para um repositório não nu no git, sua cópia de trabalho e índice não são atualizados. Como descobri, isso pode causar sérios problemas se você esquecer de atualizá-los posteriormente manualmente!

No nosso grupo, temos alguns repositórios "centrais" dos quais as pessoas clonam e pressionam, mas muitas pessoas também querem poder fazer clones de seus clones e empurrar / puxar entre eles conforme necessário, de maneira realmente distribuída. Para tornar isso seguro, quero garantir que todos os repositórios criados via "clone" ou "init" tenham um gancho pós-recebimento instalado automaticamente, que atualizará o diretório e o índice de trabalho após uma operação push estar sincronizada com o novo HEAD.

Descobri que isso pode ser feito criando um diretório de modelo com o meu gancho pós-recebimento em um subdiretório hooks, e depois fazendo com que todos no meu grupo façam:

git config --global init.templatedir /path/to/template/dir

Atualmente, meu gancho pós-recebimento é assim:

export GIT_WORK_TREE=..
git checkout -f HEAD

Este parece funcionar como desejado, mas tenho algumas incertezas sobre o comando checkout. Para fins de sincronização do diretório de trabalho e do índice com o estado em HEAD, "git checkout -f HEAD" e "git reset --hard HEAD" são equivalentes?

Eu pergunto porque, embora eu saiba que "git reset --hard HEAD" fará o que eu quero, usá-lo em um gancho pós-recebimento diminui consideravelmente as operações de push nos meus testes (parece fazer uma nova verificação de todos os arquivos , independentemente de um arquivo estar sujo ou limpo no diretório de trabalho). O "git checkout -f HEAD" parece fazer a mesma coisa muito mais rapidamente (consiga um diretório de trabalho e um índice limpos em sincronia com o HEAD), mas estou um pouco nervoso, dada a propensão do comando checkout de executar on-the-fly mescla com alterações não confirmadas do diretório de trabalho. Esse comando realmente fornecerá um diretório e índice de trabalho que correspondam exatamente ao estado em HEAD em todos os casos (incluindo, por exemplo, exclusões de arquivos, renomeados, etc.

Agradecemos antecipadamente por qualquer conselho

questionAnswers(2)

yourAnswerToTheQuestion