So che questa domanda è un po 'più vecchia, tuttavia, poiché non ho visto questa come risposta qui, mi piacerebbe condividere ciò che faccio normalmente per le installazioni e le distribuzioni basate su git a sito singolo e funziona davvero bene, anche con il lavoro da più dispositivi, posizioni e con più sviluppatori (tutti con i propri repository locali in cui operano in quanto è comune per git).
Posso consigliare caldamente la seguente configurazione:
È anche delineato (se hai bisogno di una seconda risorsa per avvolgerti la testa):
Funziona sostanzialmente (con almeno tre repository) di:
- mettere il sito web sul live-host sotto git,
- creare un nuovo repository bare git sull'host live.
- E quindi passare dal repository nudo al repository git di sviluppo locale.
Quando il lavoro è finito, spingi contro il repository nudo remoto da cui hai clonato. Il repository bare ha hook da sincronizzare con il repository live (nei codici sopra chiamati prime ).
Come impostazioni specifiche di Wordpress nel repository ho questo .gitignore:
# uploads are data, excluded from source tree
wp-content/uploads/
Il resto incl. il plugin e la configurazione del tema che tengo sotto controllo versione / configurazione. Questo mi permette di tracciare facilmente le modifiche e rivedere il codice prima di usarlo dal vivo. Posso anche unirmi più facilmente agli alberi remoti con le mie modifiche. Ciò è particolarmente utile contro il core di Wordpress che è disponibile su Github .
Funziona abbastanza bene per la maggior parte delle mie esigenze di Wordpress. Il repository nudo ti impedisce di inviare modifiche contrastanti. Si sincronizza anche con una copia remota prima di aggiornare il sito live. Ciò significa che l'aggiornamento del sito live è normalmente piuttosto veloce. A causa degli hook, puoi anche chiamare gli hook di aggiornamento di Wordpress in seguito, se lo desideri.
Se non ho sperimentato quanto questo può essere migliorato con gli hook di Github, ma normalmente non ne ho bisogno in quanto il codice è sotto il controllo della versione locale, non Github.
Per configurare un sistema del genere per la prima volta, dovresti dedicare del tempo per valutare se hai tutti gli strumenti disponibili sul tuo host remoto:
- Accesso SSH
- IDIOTA
- Una directory privata in cui puoi inserire file e sottodirectory (ad es. Per il tuo repository bare git)
Il tempo di installazione per la prima volta dovrebbe essere possibile entro due ore incl. l'intero ambiente e tu prima pubblichi push.
A seconda del tuo host, potresti anche voler proteggere la .gitdirectory dall'accesso al web. Ecco un esempio di .htaccesscodice che lo fa anche con Wordpress inserito in una sottodirectory, che lascia spazio nel repository non pubblicato online (utile):
Options -Indexes
# fix trailing slash for .git / make it disappear + .gitignore and similar files.
RedirectMatch 404 ^/\.git(.*)$
# mask 403 on .ht* as 404
<Files ~ "^\.ht">
Order Deny,Allow
Allow from all
Satisfy All
Redirect 404 /
</Files>
RewriteEngine On
RewriteBase /
# map everything into public and set environment var
# to tag the request being valid
RewriteCond %{ENV:REDIRECT_sitealias} !set
RewriteRule ^(.*)$ /public/$1 [E=sitealias:set,L]
In breve, tutto ciò che non è all'interno dell'elenco pubblico non è online. All'interno della directory pubblica può essere ad esempio il codebase di wordpress, per quel che .htaccessvi serve allora:
RewriteEngine On
# mask as 404 if directly accessed
RewriteCond %{ENV:REDIRECT_sitealias} !set
RewriteRule .* - [L,R=404]
Ciò impedisce l'accesso diretto al pubblico . Parte di questo .htaccess -foo è possibile trovare delineato qui: Le richieste a .htaccess devono restituire 404 anziché 403 . Per le variabili di ambiente è necessario verificare se funziona nel proprio ambiente. Inoltre, devi decidere se metterlo sotto il controllo della versione o meno.
Se hai più controllo sull'hosting, puoi fare più cose qui (e in modo diverso / più ottimizzato), gli esempi sopra sono mirati per tipici ambienti di hosting condiviso (che offrono GIT, alcuni utenti dicono che puoi installarlo facilmente come bene, di solito chiedo ai miei hoster di fornirli perché preferisco che si prendano cura di questo è quello per cui li pago).
Sul lato negativo, questo ha alcuni dei problemi comuni delineati anche nelle altre risposte. Una cosa di cui non sono orgoglioso, ma ciò che funziona è dare all'host di sviluppo una modifica al suo file host per fare in modo che il server del database faccia riferimento alla copia di sviluppo. Quindi puoi mantenere una configurazione del database. Esp non molto interessante. a causa delle credenziali.
Backup automatici
Tuttavia, di solito non mi interessa molto qui, ma invece eseguono backup giornalieri sui sistemi remoti che sono incrementali che a loro volta vengono archiviati in un'altra posizione remota. È facile ed economico e consente di ripristinare sia l'installazione di Wordpress sia i caricamenti di file, il database e il repository git. Anche per i miei comandi di backup potrei non essere perfettamente a posto, ma quelli funzionano per me:
mysql: mysqldump --host=%s -u %s --password=%s %s| gzip > %s
git : git gc
git bundle
files: tar --force-local -czf %s %s
Quello che suggerisco qui è di mantenere i processi intorno all'installazione di Wordpress fuori da Wordpress. Devono essere eseguiti su un sistema specifico, quindi normalmente non li hai all'interno dell'applicazione (ad esempio, l'applicazione può andare in crash ma è necessario che questi continuino a funzionare).
Abilitato per il lavoro di squadra
Un altro vantaggio è che il tuo sito è già abilitato per il lavoro di gruppo. Grazie al repository nudo aggiuntivo non puoi fare molto male e puoi persino condividere filiali remote a parte un master o una filiale live con i tuoi colleghi.