Per iniziare con Subversion, Git o un sistema di controllo versione simile per mantenere una cronologia dei miei file? [chiuso]

Mi rendo conto che questa potrebbe essere una grande domanda in superficie, ma sto cercando esempi specifici di configurazioni / flussi di lavoro che le persone usano per mantenere una cronologia delle versioni dei file modificati su un sito WordPress. Ad esempio, quando sviluppo un sito (e anche dopo che è live), apporto spesso modifiche ai file CSS e PHP, ma non ho un ottimo modo per ripristinare le versioni precedenti di quei file. Per i miei scopi, apportare modifiche a un'installazione di sviluppo locale e quindi copiarle sul sito live è spesso più un problema di quanto vorrei. Qualche suggerimento su come iniziare a utilizzare uno strumento di controllo delle versioni per tenere traccia delle modifiche ai file su un sito live?

Non sono sicuro di quanto tu sappia sull'utilizzo del controllo versione, ma di recente sono passato da SVN a Git e lo trovo fantastico!

Anche se dipende dal tuo sito live, Git ha installato (o ti permetterà). Ho anche una configurazione Git sul server live, che esegue un ramo chiamato qualcosa del genere production. Ogni volta che finisco di implementare / correggere qualcosa localmente, lo unisco nel productionramo, quindi SSH nel server del sito live e inserisco le modifiche. Batte trascinando i file su FTP quando non si sa mai se si stanno sovrascrivendo modifiche ecc.

Consiglierei di dedicare un po 'di tempo a familiarizzare con Git (se non l'hai già fatto), lo trovo molto più facile e meno seccante di SVN quando si tratta di cambiare / aggiungere un sacco di file (e diversamente da SVN non è stupido .svncartelle ovunque ).

Sono su un Mac, quindi mi dispiace se nessuna di queste si applica, ma uso Coda come editor di codice e ho installato Git tramite Ports (usando Porticus).

Se dovessi impostare nuovamente tutto, farei:

1. Installa Coda

2. Installa Porticus (che richiederà l'installazione di Porte, ma ci sono informazioni su quella pagina)

3. Dopo aver installato Porticus, aprilo, cerca "git-core" e installalo.

4. Scarica e installa GitX 7-5

5. C'è una buona guida sull'impostazione di un repository git qui , ma alla sua base: 1. Apri Terminale. 2. cddove vuoi che risieda il tuo sito. $: mkdir mysite && cd mysite3. $: git inite questo è tutto! Se aggiungi file a questa cartella, vai al passaggio successivo

6. Dopo aver impostato un repository GIT localmente (sopra l'articolo), se apri quella directory in GitX sarai in grado di eseguire il commit di cose ecc.

Configurare tutto sul server può essere un po 'complicato, ho un account MediaTemple e un account Dreamhost che hanno entrambi GIT pronto all'uso. Il collegamento nel passaggio 5 spiega come aggiungere un repository remoto, quindi non è necessario farlo fino a quando non si desidera portare il proprio sito live nell'equazione. Consiglierei di far funzionare prima tutto a livello locale (a differenza di SVN, GIT non richiede un repository remoto, quindi per il momento puoi fare tutto sul tuo computer).

Uso SVN per il controllo della versione con tutto ciò che faccio nello sviluppo di WordPress. In realtà ho iniziato in questo modo perché avevo bisogno di SVN per lo sviluppo di plug-in ... una volta iniziato lì, è stata un'estensione naturale per continuare a utilizzare SVN per temi e script personalizzati sui siti client.

Plug-in

Poiché i plug-in sono già ospitati sul server di WordPress, ho appena verificato un plug-in direttamente nella /wp-content/plugins/directory della mia installazione locale di WordPress (eseguo WAMP sulla mia casella di sviluppo). Quindi apporto modifiche alla mia copia locale e, quando è pronto per lo showtime, mi impegno nel repository. È un processo regolare lì, nessun caricamento / download e verifica istantanea che le mie modifiche hanno funzionato.

Temi

I temi sono leggermente diversi, in particolare quando si crea per un client. Creo un repository locale (ho una Rpartizione sul mio disco rigido appositamente per questo scopo) e controllo il repository vuoto direttamente nella mia /wp-content/themesdirectory. Quindi apporto le modifiche necessarie e lo sviluppo fino a quando non è pronto, eseguendo revisioni mentre procedo.

Quando sono pronto a pubblicare il tema sul server di produzione di un client, esporto il repository, comprimilo e utilizzo i temi nativi >> Aggiungi nuova funzionalità in WordPress. Funziona anche con plug-in personalizzati (che non sono ospitati da WordPress).

Utensili

Come ho detto, utilizzo WAMP sul mio computer locale per eseguire un'installazione di sviluppo di WordPress. Funziona perfettamente sulla mia scatola e mi permette di eseguire tutte le istanze di WordPress di cui ho bisogno per un particolare progetto.

Per SVN, utilizzo Tortoise SVN . È gratuito, straordinariamente facile da usare e si integra con la struttura di file e comandi di Windows. L'aggiornamento, il commit e l'esportazione sono tutti semplici clic del tasto destro, selezionare le operazioni di comando. L'uso di "Esporta" ti consente di inviare l'intera cartella (senza le fastidiose .svncartelle) direttamente a qualsiasi posizione di tua scelta - Esportazione spesso sul desktop. Anche zippare la cartella è un'operazione del tasto destro del mouse e WordPress gestisce il caricamento.

Il trasferimento manuale dei file può essere una seccatura, in particolare se si continua a cambiare un file ma non tutti. Se invece FTP sull'intera directory con "sovrascrivi tutto" selezionato, è molto più semplice sostituire i vecchi file (e non è necessario tenere traccia di quali modifiche e quali no). È come la vecchia installazione di 5 minuti che aveva WordPress: basta sostituire tutto con la nuova versione.

Personalmente, penso che sia un esercizio divertente installare SVN / GIT e gestirlo, ma se puoi oscillare $ 15 al mese, Beanstalk vale ogni centesimo. Gestiscono l'intero server per te. http://beanstalkapp.com/ Gli strumenti di distribuzione FTP sono fantastici. Il mio distribuisce automaticamente la versione sul mio server di gestione temporanea quando, ad esempio, eseguo il commit

Un altro modo per ottenere un controllo delle versioni dei file personali è utilizzare la casella di riepilogo. Ogni volta che salvi un file nel tuo dropbox, la traccia viene rintracciata e puoi ripristinarla in qualsiasi versione precedente in seguito. Tu e un altro sviluppatore o gruppo potete condividere una cartella del drop box. Concesso, ciò non comporta tronchi, fusioni, ecc., Ma rende molto facile per un team distribuito lavorare su un sito Web. Non puoi davvero lavorare sugli stessi identici file contemporaneamente.

Manteniamo la nostra copia di lavoro SVN nella casella personale, quindi eseguo il commit dei file al momento della scrittura. I miei designer non eseguiranno il commit dei file o non affronteranno SVN, quindi questo è il compromesso.

Preferisco SVN perché non ho bisogno di tutto il trunking per cui GIT è così eccezionale e ci sono strumenti GUI migliori disponibili di SVN.

Mi piace molto Aptana , ha la sovversione integrata e puoi connetterti al tuo server con ftp / sftp facilmente e fare il push dei file, un'altra grande caratteristica che ha è che se crei un nuovo progetto php e includi il "intero" WordPress cartella (con wp-admin, wp-Includes) ottieni il completamento del codice nei file dei temi.

Nella mia configurazione il repository è locale.

Chiedete "ma sto cercando esempi specifici di configurazioni / flussi di lavoro che le persone usano per mantenere una cronologia delle versioni dei file modificati su un sito WordPress" ma menzionate anche prodotti :)

In alto, come risposta, un elenco di strumenti e alcune migliori pratiche, ma mi concentrerò qui sui flussi di lavoro: NON SONO SPECIFICI DI WORDPRESS:

Ma per gli esempi generali / configurazioni / flussi di lavoro:

Per i principianti: ci sono modelli CM, quindi indipendenti dagli utensili. Google su CM Patterns, molti libri là fuori, persino le community di wiki, ad esempio http://www.cmcrossroads.com/forums .

Ci sono anche guide sull'impostazione di una strategia di flusso valida (strategia di flusso di Google), ecc ...

Non credo che ci sia qualcosa di speciale nelle implementazioni di WordPress rispetto a CM Management, incluso lo sviluppo parallelo distribuito su grandi fabbriche Siebel, SAP, Informatica, Java ecc. È davvero quasi predefinito.

Quello che manca, penso, è che nessuno ha scritto un CMplan per lo sviluppo di WordPress (ancora) (IEEE). Una volta che qualcuno lo ha fatto (indipendentemente dallo strumento). I requisiti possono essere compilati, credo, con qualsiasi strumento.

Penso che il motivo per cui il piano non è stato scritto sia che quasi tutte le implementazioni di WordPress siano ancora eseguite da 1 persona con una semplice configurazione di sviluppo-produzione, quindi non con più sviluppatori / progettisti nella fase di costruzione che devono distribuire versioni diverse che sono in esecuzione nella ambiente di test, ad esempio.

il piano CMP inizia con l'identificazione di tutti gli elementi della configurazione in altre parole: crea un elenco di tutti i tipi di elementi della configurazione presenti in un'implementazione di WordPress tra cui app, plugin, database, documentazione, aiuto, contenuto, file di configurazione, note di rilascio (!), ecc. ..). Questo è un buon inizio. Quindi decidi quali vuoi portare sotto CM.

Quindi, decidere quali sono le cause delle modifiche su questi elementi della configurazione, ad esempio una richiesta da parte del cliente di un bugfix o un aggiornamento necessario. Se fatto bene, questo porta a una situazione in cui hai la sensazione che le cose siano sotto controllo.

Decisioni come la fusione dalla produzione allo sviluppo e il modo di gestirlo fanno parte di quel capitolo (2 modelli principali qui) (anche se ovviamente dovresti cercare di minimizzare questi hotfix).

Solo più tardi cerca uno strumento per eseguire CM da un lato (che include la gestione delle versioni come uno degli strumenti) e cambia gli strumenti di gestione dall'altro lato (che ti mantengono sano di mente).

Penso che sia il miglior flusso di lavoro da cui iniziare, dato che ho cercato su Google nessuno ancora. Penso che una volta che la prima persona abbia scritto un piano WordPress CM (secondo IEEE) ogni altra persona WordPress nel mondo può copiare quel piano e apportare modifiche e implementare i modelli nei loro strumenti.

Non è troppo lavoro / troppo pesante: dipende se hai una società o no: un giorno potresti risparmiare un bel po 'di tempo per avere un buon piano CM.

Sono su un host condiviso, quindi non posso installare SVN o qualcosa del genere. Uso Mercurial per il controllo della versione sul mio computer di casa. Uso la sincronizzazione FTP di Beyond Compare per sincronizzare le cartelle locali e remote.

sto usando git. è semplice. devi solo capire un comando semplice come clonare, comit, push, pull e sei pronto per partire. questo è il base.

tuttavia, se lo usi più come coordinare una squadra per lavorare su un prodotto, allora è un altro livello. ma alla fine, valeva la pena usare git o qualsiasi controllo di versione. ci sono fatti quando succede la merda.