Share
Se hai un plug-in ospitato nel repository di WordPress, sarai abbastanza familiare con SVN e alcuni dei suoi comandi. In questo tutorial ti mostrerò come puoi usare Git, un altro sistema di controllo delle versioni reso popolare da GitHub, per pubblicare e mantenere il tuo plug-in.
Git e SVN sono entrambi esempi di sistemi di controllo versione. Il repository di WordPress utilizza quest'ultimo (se hai un plug-in ospitato su WordPress avrai familiarità con il "check in" per apportare modifiche a questo repository). Entrambi consentono di tenere traccia delle modifiche al codice, ma ci sono grandi differenze tra loro su come lo fanno.
SVN si basa su un singolo "repository centrale" del codice (nel nostro contesto: il repository di plug-in di WordPress). Ogni volta che vuoi modificare il tuo plug-in, devi creare una copia locale, apportare le modifiche e quindi "archiviare" queste modifiche nel repository di WordPress.
Git è un sistema di controllo della versione decentralizzato. Piuttosto che avere solo una copia locale del tuo plug-in, hai un intero clone del tuo repository plug-in, completo di tutte le sue modifiche. Il repository ora esiste a pieno diritto sul tuo computer. Puoi eseguire il commit e tenere traccia delle modifiche, annullare le modifiche o "ramificare" il plug-in in diverse direzioni sul tuo computer locale. Solo una volta che sei felice di aggiornare il tuo plug-in, trasferisci le tue modifiche nel tuo repository di WordPress per renderle pubbliche.
In questo tutorial presumo che tu abbia un plug-in ospitato nel repository di plug-in di WordPress, o almeno che tu abbia approvato la tua richiesta di hosting. Se non sei sicuro di come ottenere il tuo plug-in ospitato da WordPress, ti suggerisco di leggere il nostro articolo su come pubblicare nel repository dei plugin di WordPress.
Esistono numerosi argomenti a favore e contro l'uso di Git su SVN (e in generale dei sistemi di controllo delle versioni decentralizzati). Molti di questi provengono dai modi fondamentalmente diversi in cui Git e SVN seguono i cambiamenti. Un'eccellente analisi approfondita di Git e SVN può essere trovata nell'articolo di Git vs SVN di CodeForest, ma per lo sviluppatore di WordPress:
Uno svantaggio dell'uso di Git sta nel fatto che funziona con un repository SVN. In realtà non è così difficile grazie a git svn, e questo articolo è qui per guidarti attraverso di esso.
Se non lo hai già fatto, ti consigliamo di installare Git. Come installare Git è trattato abbastanza bene nel libro Git Community e nel libro Pro Git (entrambi eccellente risorse se sei nuovo a Git). Come installare Git dipenderà dal tuo sistema operativo, così come saranno disponibili i programmi della GUI. In questo tutorial farò tutto attraverso la linea di comando - e ti incoraggio a fare altrettanto. Alla fine dell'articolo suggerirò alcuni programmi GUI che puoi usare, ma di solito li uso solo per visualizzare i rami del repository.
Come accennato in precedenza, con Git non si esegue il "check out" di una copia del plug-in: si clona il repository, con una cronologia delle modifiche apportate e tutti i relativi rami e tag. Il passaggio 1 è quindi quello di clonare il repository ospitato da WordPress del plug-in. Ad esempio pubblicherò un plug-in "Post Type Archives Link" basato su un tutorial precedente. Quindi (una volta che sei stato accettato nel repository di WordPress) apri la tua interfaccia a riga di comando e vai a dove vuoi memorizzare la versione locale del tuo plug-in. Lo inserirò in una cartella chiamata 'plugin'. Una volta lì, vogliamo dire a Git dove trovare il nostro plug-in. Al momento della scrittura ci sono circa 20.000 plug-in ospitati nel repository di WordPress e oltre 500.000 revisioni. Non vogliamo aspettare che Git dia una scorsa a ognuno di questi per trovare il nostro plug-in. Quindi, prima di tutto, troviamo la revisione del nostro plug-in (vogliamo la sua intera cronologia). Per fare questo otteniamo il primo log del tuo plug-in (quando è stato originariamente aggiunto al repository):
svn log -r 1: HEAD --limit 1 http://plugins.svn.wordpress.org/your-plug-in-name
Penserà per un po 'e poi dovresti vedere qualcosa di simile a questo:
r520657 | plugin-master | 2012-03-19 03:56:31 +0000 (Lun, 19 Mar 2012) 1 riga
Il primo numero, '520657' per il mio plug-in, è la prima revisione. Lo useremo nel prossimo comando che dice a Git di clonare la cronologia dei nostri plug-in. Sostituisci XXXXXX con il tuo numero di revisione.
git svn clone -s -rXXXXXX --no-minim-url http://plugins.svn.wordpress.org/your-plug-in-name cd tuo-plugin-nome git svn fetch git svn rebase
Il '-S'dice a Git di aspettarsi il layout standard (Tag, Trunk, Branches) di un repository SVN. Il '--no-minimizzare-url'si ferma guardando fuori dalla tua cartella di plug-in. Assicurati che non manchi. Se lo lasci fuori, potresti finire per copiare l'intero repository dei plug-in di WordPress. Il -rXXXXXX dice a Git quale revisione cercare. Se lo lasci fuori, Git effettuerà una ricerca attraverso l'intera cronologia del repository. Sono oltre 500.000 revisioni. Ho lasciato questo fuori una volta e ci sono voluti circa due ore. Con esso, dovrebbe richiedere solo pochi minuti.
Una volta fatto, dovresti scoprire che è stata creata una cartella chiamata 'your-plug-in-nome'all'interno della cartella' Plugin '. Esploriamo un po '. Vai al 'your-plug-in-nome'cartella ed esegui un comando per vedere quali' rami 'esistono:
git branch -a
Questo elencherà tutti i rami, locali e remoti. L'unico ramo locale dovrebbe essere Master (l'asterisco indica che questo è il ramo in cui ti trovi). Gli altri rami sono il "tronco" e, se ne hai, un ramo per ogni tag (SVN considera i tag come rami, ma Git è un po 'più intelligente di quello).
Andando alla tua 'cartella locale', 'plugins / your-plugin-nome', dovresti vedere i tuoi file di plug-in (se ce ne sono). Prima di creare o modificare file, creeremo un ramo separato su cui lavorare.
Aggiornare: I comandi di cui sopra sono stati aggiornati a causa di un problema notato nei commenti di Neerav e John Eckman. Il codice sopra ora riflette la raccomandazione di Stephen Harris.
Uno dei vantaggi dell'utilizzo di Git è che puoi facilmente mantenere una versione del tuo plug-in su GitHub. Ciò rende il tuo plug-in più accessibile agli altri sviluppatori, che potrebbero suggerire miglioramenti o persino apportare le proprie modifiche che potresti inserire nel tuo repository. Se sei già configurato con GitHub, a questo punto potresti voler inserire il tuo plug-in nel tuo account. Per fare ciò, prima crearti un nuovo repository sul tuo account GitHub, quindi aggiungilo come un ramo remoto al tuo repository locale:
git remote add origin [email protected]:/ .idiota
'il tuo nome utente'si riferisce al tuo nome utente GitHub e'your-repo-nome'si riferisce al nome del repository che hai creato su GitHub. Quindi devi solo trasferire il tuo repository locale:
git push origin master
Creeremo un nuovo ramo "lavoro". È all'interno di questo ramo che dovremmo modificare il nostro plug-in, apportare modifiche e aggiungere funzionalità, ecc. Ciò significa che il nostro ramo "Master" è mantenuto nel suo stato originale. Questo ci consente di tornare al ramo Master e di ripartire di nuovo. In particolare, supponiamo che un grosso bug si trovi nel tuo plug-in mentre stai lavorando su alcune nuove funzionalità nel tuo ramo "di lavoro". Puoi tornare al tuo ramo "master" (che non include nessuna delle funzionalità su cui stai lavorando attualmente), commettere una correzione per il bug e poi inviarlo al repository di WordPress. È quindi possibile tornare al proprio ramo di lavoro e continuare da dove si era interrotto. (Nota: Git non crea copie dei tuoi file - ci sarà sempre un solo set di file nella tua cartella locale. Ciò che questi file contengono dipenderà dal ramo in cui ti trovi.)
In effetti, è una buona idea creare un ramo per ogni nuova funzione che si aggiunge al proprio plug-in. Quando hai finito devi semplicemente unirli di nuovo nel ramo principale. Se ciò provoca "conflitti", ti verrà chiesto di risolverli manualmente.
Per prima cosa crea un ramo chiamato "lavoro":
git branch work
Quindi 'check out' (vai a) ramo 'lavoro':
lavoro di cassa
Un messaggio ti dirà che sei passato al ramo "lavoro". Ora usa il tuo editor di testo preferito per aprire i file del plug-in nella tua cartella locale (o crearli se non ce ne sono ancora). Una volta che ne hai creati alcuni, potresti voler vedere quali file sono stati modificati. Lo fai con il semplice comando:
stato git
Questo elencherà i cambiamenti di cingolato e untracked File. Potrebbero esserci dei file che non vuoi che Git disturbi del monitoraggio (come i file temporanei), ma se hai aggiunto nuovi file alla cartella dovrai dire a Git di seguirli. Puoi farlo con il comando:
aggiungi git
Ho creato due file 'post-tipo-archivio-links.php' e 'metabox.js'nella mia cartella locale, quindi li ho aggiunti per dire a Git di seguirli. Devi assicurarti di tracciare il tuo readme file.
Puoi anche visualizzare le modifiche dall'ultimo commit (è qui che un programma GUI diventa molto utile)
git diff
Una volta che vuoi commettere le modifiche al tuo repository locale:
git commit -a -m "Abc to xyz"
fornendo undettagliato) messaggio delle modifiche contenute nel commit.
Nel processo di modifica puoi (e dovresti) impegnarti il più spesso possibile, ma in modo logico, preferibilmente con un commit per ogni "cosa" che fai. Dovresti assicurarti che non ci siano errori evidenti nei tuoi commit. 'Annullare' un commit è veloce e indolore: lo fai eseguendo un altro commit che inverte quello precedente:
git revert HEAD
(Ti verrà richiesto un messaggio per descrivere questo commit.)
Supponiamo che tu ora sia nella posizione in cui desideri trasferire tutte le modifiche al repository SVN. Prima di farlo, dobbiamo mettere in evidenza qualcosa. Git ti incoraggia a impegnarti spesso, ed è una buona pratica farlo ... per sviluppo. Tuttavia, il tuo repository di plug-in WordPress è lì per distribuzione. Non ha bisogno di ogni singolo commit. In realtà, non è così volere o, come Otto (contributore principale di WordPress) avverte:
"Se ti prendo a bordo [spingendo ogni commit separatamente], ti banetterò da WordPress.org L'SVN ha solo bisogno della tua versione finale impegnata su di esso, non dell'intera storia delle centinaia di modifiche che hai fatto usando Git. Appiattisci le tue modifiche in un singolo commit. "
Per evitare questo, quando siamo pronti a spingere nel repository di WordPress, uniamo tutti i commit in un commit. Ci sono un paio di modi per farlo. Ci uniremo (e simultaneamente schiacceremo) i nostri cambiamenti dal nostro ramo di lavoro al nostro ramo principale. Quindi tutte le nostre modifiche appaiono come un commit sul ramo principale. Quindi eliminiamo il ramo di lavoro e spingiamo il ramo master al trunk SVN del nostro plug-in.
Per prima cosa, vogliamo tornare al ramo Master:
git checkout master
Quindi schiaccia e unisci le modifiche del ramo di lavoro nel master:
git merge --squash work
Se sono state apportate modifiche al ramo principale, potrebbero verificarsi conflitti nell'unione. Ti verrà richiesto di risolvere manualmente questi conflitti prima che l'unione possa essere completata. Una volta uniti, esegui il commit delle modifiche (questo commit conterrà tutti i commit dal nostro ramo di lavoro):
git commit -a -m "Apportate modifiche a, b, c, d"
Infine, cancelliamo il ramo di lavoro
git branch -D lavoro
Se hai più rami in cui desideri unire, puoi farlo per ognuno di essi. Esistono metodi alternativi, che non tratterò, di appiattimento della cronologia (come il rebasing interattivo).
A questo punto potresti, se lo desideri, trasferire le ultime modifiche al tuo account GitHub:
git push -u origine master
Per inviare al repository di WordPress, prima assicuriamo che il nostro repository locale sia 'aggiornato':
git svn rebase
Git andrà quindi a recuperare il tuo repository subversion e ad unire le eventuali modifiche con le modifiche appena apportate. Normalmente, non dovrebbero esserci modifiche al repository di WordPress, quindi dovresti vedere il messaggio: Il master del ramo attuale è aggiornato.
Ora possiamo trasferire le modifiche al repository di WordPress
git svn dcommit
Git potrebbe quindi richiedere le credenziali di WordPress.org. Una volta inserite, le modifiche verranno applicate al repository di WordPress. A breve dovresti ricevere una e-mail dal repository di WordPress, che ti informa dei commit.
Attualmente, queste modifiche si installeranno nel bagagliaio. Cosa succede se vogliamo taggare una nuova versione del nostro plug-in? Durante la creazione della versione successiva per il plug-in, è necessario aggiornare il file Leggimi, in modo che il tag stabile punti alla nuova versione (ad esempio "2.0"). Dovresti anche aver aggiornato le informazioni dell'intestazione del plug-in nel tuo your-plug-in-name.php file. Se hai dimenticato di farlo, esegui semplicemente la procedura sopra riportata, dopo aver apportato tali modifiche.
Una volta che il tuo 'trunk' è completamente aggiornato (incluse le ultime informazioni sulla versione), dobbiamo semplicemente creare il nuovo tag nel repository di WordPress:
git svn tag "2.0"
Questo copia tutto nel bagagliaio in tag / 2.0 (cosa si ottiene normalmente in SVN con tag trunk svn cp / 2.0).
Se si desidera taggare la versione nel proprio repository locale:
git tag -a 2.0 -m "Tagging 2.0"
Simile a quello che abbiamo fatto con il repository di WordPress, assicurati che i nostri repository siano d'accordo, quindi spingi le nostre modifiche e tag:
git pull --rebase origine master git push origine master git push origine - tag
Infine ci sono un paio di "cheat sheet" di Git che possono tornare utili: qui e qui.
Accentsconagua