Perché utilizzare un repository git bare per l'implementazione del sito Web?

Question

Sto iniziando a distribuire alcuni plug-in del sito web tramite git.

Ho svolto una serie di esercitazioni sul Web e tutti consigliano di creare un repository remoto nullo sul server Web con un hook post-aggiornamento per il checkout nella directory DocumentRoot. Ho ottenuto tutto questo senza troppi problemi.

Perché stiamo separando il repository dalla directory di lavoro? Cosa c'è di sbagliato nell'usare la directory DocumentRoot come repository e quindi usare htaccess per impedire l'accesso pubblico a qualsiasi contenuto .git?

Answer 1

In realtà i rischi per la sicurezza insiti in un htaccess configurato male sono una buona ragione di per sé, ma il motivo principale è che, per impostazione predefinita, non è possibile passare al repository di un repository non scoperto. (. Può essere attivato, ma poi richiede un git reset --hard per aggiornare l'albero di lavoro, e non è più semplice che avere una directory di distribuzione separata)

Answer 2

Ci sono diverse domande qui che, mentre correlate sono in realtà separata:

1 - Perché stiamo separando il repository dalla directory di lavoro?

Poiché git impedisce di passare a un ramo estratto per impostazione predefinita. Pertanto, non è possibile passare mai a una directory di lavoro perché, per definizione, se è su disco viene estratto.

2 - Tutti loro si raccomanda di creare un repository remoto nuda sul web server

domanda implicita è: why a bare repo? Beh, un pronti contro termine a nudo è semplicemente un repo git con niente estratto. Pertanto è possibile spingere a qualsiasi filiale su un repository nudo. Alcune persone considerano questo più semplice da mantenere.

Seconda domanda implicita: is there an alternative to bare repos? Sì, come accennato, la limitazione è solo sui rami controllati. In questo modo è ancora possibile passare liberamente a un ramo non controllato, magari "deploy" e quindi avere un hook per unire quel ramo non controllato alla propria directory di lavoro.

Answer 3

1. Usa DocumentRoot come directory di lavoro git:

   • Usa tirare per l'aggiornamento, hanno bisogno di trigger esterno o cron o manuale eseguirlo
   • bisogno di limitare l'accesso a http.directory git
   • modifico istante/incidere in DocumentRoot può usare diff per confrontare con la storia git, buono per il debug/trovare problema
   ramo
   • Switch è facile

2. Usa separata nudo git repostory

   • L'utente può inviare a questo repository e utilizzare il gancio post-aggiornamento per aggiornare DocumentRoot
   • Di solito nessuno vuole eseguire il trucco istantaneo in un repository nudo, la modifica in DocumentRoot non può diff con la cronologia git
   • DocumentRoot è pulito
   • ramo interruttore può essere necessario modificare gancio

Così, sembra separato nudo git repo è più pulito e facile da usare, se necessario attivare un gancio post-aggiornamento.

Il piano 1 è anche in grado di funzionare, usarlo in un piccolo progetto o sviluppare un mechine va bene, ma attenzione al privilegio di accesso alla directory .git, specialmente quando si cambia server web. es: nginx non supporta .htaccess, che viene spesso memorizzato in git insieme ad altri file di progetto.