Share
Dacă aveți un plug-in găzduit în depozitul WordPress, atunci veți fi destul de familiarizat cu SVN și cu unele dintre comenzile sale. În acest tutorial vă vom arăta cum puteți utiliza Git, un alt sistem de control al versiunilor popularizat de GitHub, pentru a vă publica și întreține plug-in-ul.
Git și SVN sunt ambele exemple de sisteme de control al versiunilor. WordPress utilizează ulterior (dacă aveți un plug-in găzduit pe WordPress veți fi familiarizați cu "check in" pentru a face schimbări în acest depozit). Ambele vă permit să urmăriți modificările aduse codului dvs., dar există mari diferențe între ele în ceea ce privește modul în care acestea fac acest lucru.
SVN se bazează pe un singur "depozit central" al codului (în contextul nostru: depozitul plug-in WordPress). De fiecare dată când doriți să vă modificați pluginul, trebuie să faceți o copie locală, să efectuați modificările și apoi să "verificați" aceste modificări în depozitul WordPress.
Git este un sistem de control al versiunii descentralizate. Mai degrabă decât având doar o copie locală a plug-in-ului - aveți o clonă completă a depozitului dvs. plug-in, completat cu toate modificările sale. Depozitarul există acum pe cont propriu pe computerul dvs. Puteți să efectuați și să urmăriți modificările, să reveniți la modificări sau să "ramificați" pluginul în diferite direcții, toate pe computerul local. Doar odată ce vă veți bucura să vă actualizați pluginul, atunci veți împinge modificările în depozitul dvs. WordPress pentru a le face publice.
În acest tutorial presupun că aveți un plug-in găzduit pe depozitul plug-in WordPress sau cel puțin ați aprobat cererea de găzduire. Dacă nu sunteți sigur cum să obțineți plug-in-ul găzduit de WordPress, vă sugerez să citiți articolul despre cum să publicați în depozitul de plugin-uri WordPress.
Există numeroase argumente pentru și împotriva utilizării Git peste SVN (precum și a sistemelor de control al versiunii descentralizate, în general). Multe dintre acestea provin din modurile fundamental diferite ale schimbărilor Git și SVN. O analiză excelentă în profunzime a lui Git și SVN poate fi găsită în articolul CodeForest Git vs SVN, dar pentru dezvoltatorul WordPress:
Un dezavantaj al folosirii lui Git este acela de a juca frumos cu un depozit SVN. De fapt, nu-i așa de greu git svn, și acest articol este aici pentru a vă ghida prin el.
Dacă nu ați făcut-o deja, veți dori să instalați Git. Cum se instalează Git este acoperită destul de bine în cartea comunitară Git și în cartea Pro Git (ambele excelent resurse dacă sunteți nou la Git). Cum se instalează Git va depinde de sistemul dvs. de operare, precum și de programele GUI care vă sunt disponibile. În acest tutorial voi face totul prin linia de comandă - și vă încurajez să faceți același lucru. La sfarsitul articolului voi sugera cateva programe GUI pe care le puteti folosi, dar, de obicei, le folosesc doar pentru a vizualiza ramurile depozitului.
Așa cum am menționat anterior, cu Git nu "verificați" o copie a plug-in-ului - clonați depozitul, completând istoricul modificărilor făcute și toate filialele și etichetele sale. Pasul 1 este de a clona depozitul găzduit de WordPress al plug-in-ului. Ca exemplu, voi publica un plug-in "Post Type Archives Link" bazat pe un tutorial anterior. Deci (odată ce ați fost acceptat în depozitul WordPress) deschideți interfața liniei de comandă și navigați la locul în care doriți să stocați versiunea locală a pluginului. O să o pun într-un director numit "Plugin-uri“. Odată ce vrem să-i spunem lui Git unde să găsească plug-in-ul nostru. La momentul redactării, există aproape 20.000 de plug-in-uri găzduite în depozitul WordPress și peste 500.000 de revizii. Nu vrem să așteptăm ca Git să tragă prin fiecare dintre ei pentru a găsi plug-in-ul nostru. Deci, mai întâi de toate, găsim ce revizie începe plug-in-ul nostru (dorim să avem istorie întreagă). Pentru aceasta, primim primul jurnal al plug-in-ului dvs. (când a fost inițial adăugat la depozit):
svn log -r 1: HEAD - limită 1 http://plugins.svn.wordpress.org/your-plug-in-name
Se va gândi un timp și apoi ar trebui să vedeți ceva de genul acesta:
r520657 | plugin-master | 2012-03-19 03:56:31 +0000 (Luni, 19 Mar 2012) | 1 rând
Primul număr, "520657" pentru plug-in-ul meu, este prima revizie. O vom folosi în următoarea comandă care îi spune lui Git să cloneze istoria plug-in-ului. Înlocuiți XXXXXX cu numărul de revizie.
git svn clone -s -rXXXXXX --no-minimize-url http://plugins.svn.wordpress.org/your-plug-in-name cd-plugin-numele dvs. git svn fetch git svn rebase
''-s"îi spune lui Git să aștepte structura standard (Tag, Trunk, Branches) a unui depozit SVN. ''--nu-minimiza-url"oprește căutarea în afara dosarului dvs. de plug-in. Asigurați-vă că nu lipsește. Dacă l-ați lăsat afară, ați putea termina copierea întregului depozit plug-in WordPress. -rXXXXXX spune Git ce revizie să caute. Dacă lăsați acest lucru, Git va căuta în întreaga istorie a depozitului. Sunt peste 500.000 de revizuiri. Am lăsat asta odată și au durat aproximativ două ore. Cu aceasta, ar trebui să dureze doar câteva minute.
Odată ce ați terminat, ar trebui să găsiți că a fost creat un dosar numit "dvs. de plug-in-name"în dosarul" Plugin-uri ". Să explorăm un pic. Navigați la secțiunea "dvs. de plug-in-name"și rulați o comandă pentru a vedea ce" ramuri "există:
git branch -a
Aceasta va lista toate filialele, locale și de la distanță. Singura ramură locală ar trebui să fie Master (asteriscul indică faptul că acesta este sucursala pe care vă aflați). Cealaltă ramură (ramuri) sunt "trunchiul" și, dacă aveți, o ramură pentru fiecare etichetă (SVN tratează etichetele ca ramuri, dar Git este puțin mai inteligent decât asta).
Mergeți la dosarul dvs. local,plugins / ta-nume-plugin", ar trebui să vedeți fișierele plug-in (dacă există). Înainte de a crea sau de a edita fișierele de acolo, vom crea o ramură separată pentru a lucra.
Actualizați: Comenzile de mai sus au fost actualizate din cauza unei probleme menționate în comentariile de mai jos de Neerav și John Eckman. Codul de mai sus reflectă recomandarea lui Stephen Harris.
Unul dintre avantajele utilizării Git este că puteți să mențineți cu ușurință o versiune a plug-in-ului pe GitHub. Acest lucru face ca plug-in-ul dvs. să fie mai accesibil pentru alți dezvoltatori, care pot sugera îmbunătățiri sau chiar pot face modificări proprii pe care le puteți trage în propriul depozit. Dacă sunteți deja configurat cu GitHub, este posibil să doriți în acest moment să vă împingeți pluginul în contul dvs. Pentru a face acest lucru, mai întâi creați-vă un nou depozit în contul dvs. GitHub și apoi adăugați-l ca pe o ramură la distanță în depozitul local:
git la distanță adaugă originea [email protected]:/ .git
'nume de utilizator"se referă la numele dvs. de utilizator GitHub și la"dvs.-repo-name"se referă la numele depozitului pe care l-ați creat pe GitHub. Apoi, împingeți repositorul local:
git push master de origine
Vom crea o nouă "lucrare" a filialei. Este în interiorul acestei ramuri că vom modifica plug-in-ul nostru, vom face modificări și vom adăuga caracteristici etc. Aceasta înseamnă că ramura noastră "Master" este păstrată în starea inițială. Acest lucru ne permite să revenim la sucursala Master și să ne despărțim din nou. În special, să presupunem că un bug major se găsește în plug-in-ul dvs. în timp ce lucrați la unele caracteristici noi în sucursala dvs. "de lucru". Puteți să reveniți la sucursala dvs. "master" (care nu include niciuna dintre funcțiile pe care lucrați în prezent), să faceți o remediere a erorii și apoi să o împingeți în depozitul WordPress. Apoi, puteți reveni la filiala dvs. de lucru și puteți continua unde ați rămas. (Notă: Git nu creează copii ale fișierelor - în dosarul dvs. local va exista întotdeauna doar un singur set de fișiere. Ce conține aceste fișiere depinde de ce ramură sunteți.)
De fapt, este o idee bună să creați o ramură pentru fiecare funcție nouă pe care o adăugați la plug-in-ul dvs. Când ați terminat, purtați-le pur și simplu în ramura principală. Dacă acest lucru cauzează "conflicte", vi se va cere să rezolvați aceste probleme manual.
Mai întâi creați o ramură numită "muncă":
git work branch
Apoi, "check out" (mergi la) branch 'work':
git checkout
Un mesaj vă va spune că ați trecut la filiala "muncă". Acum, utilizați editorul de text preferat pentru a deschide fișierele plug-in-ului în folderul local (sau creați-le dacă nu există încă). Odată ce ați făcut câteva, este posibil să doriți să vedeți ce fișiere ați schimbat. Faceți acest lucru cu o comandă simplă:
git status
Aceasta va lista modificările din pe șenile și untracked fișiere. Pot exista fișiere pe care nu doriți ca Git să deranjeze urmărirea (cum ar fi fișierele temporare), dar dacă ați adăugat fișiere noi în director, va trebui să îi spuneți lui Git să le urmărească. Puteți face acest lucru cu comanda:
adăugați git
Am creat două fișiere "post-tip arhiva-links.php' și 'metabox.js"în dosarul meu local, așa că i-am adăugat să le spună lui Git să le urmărească. Trebuie să vă asigurați că vă urmăriți Citește-mă fişier.
Puteți, de asemenea, să vedeți modificările de la ultimul dvs. angajament (acesta este locul în care un program GUI devine foarte util)
git diff
Odată ce doriți să faceți schimbările la depozitul local:
git commit -a -m "A făcut abc la xyz"
furnizând un (detaliat) a modificărilor conținute în comitet.
În procesul de a face schimbări, puteți (și ar trebui) să comiteți cât mai des posibil - dar într-un mod logic, de preferință cu un angajament pentru fiecare "lucru" pe care îl faceți. Ar trebui să vă asigurați că nu există nici o eroare evidentă în angajamentele dvs. fie. "Anularea" unei comitete este rapidă și nedureroasă: faceți acest lucru efectuând o altă comitet care inversează cel precedent:
git revin HEAD
(Vi se va solicita un mesaj pentru a descrie această comitere.)
Să presupunem că acum vă aflați într-o poziție în care doriți să împingeți toate modificările dvs. la depozitul SVN. Înainte de a face acest lucru, trebuie să luăm în considerare ceva. Git vă încurajează să vă comiteți frecvent și este o practică bună să o faceți ... pentru că dezvoltare. Cu toate acestea, depozitul de plugin-uri WordPress este acolo distribuire. Nu are nevoie de fiecare comitet. De fapt, într-adevăr nu vrei fie, așa cum avertizează Otto (contribuitorul principal al WordPress)
"Dacă vă prindeți [împingând fiecare comitere separat], atunci vă voi interzice din WordPress.org. SVN are nevoie doar de versiunea finală de lucru dedicată acesteia, nu întreaga istorie a sutelor de modificări pe care le-ați făcut folosind Git. Ajustați modificările dvs. la o singură angajare. "
Pentru a evita acest lucru, atunci când suntem gata să împingeți în depozitul WordPress, fuzionăm toate comitetele într-un singur angajament. Există câteva modalități de a face acest lucru. Vom combina (și, simultan, vom înfunda) schimbările noastre de la ramura noastră de lucru în sucursala noastră. Apoi, toate schimbările noastre apar ca pe o comitere pe ramura principală. Apoi ștergem ramura de lucru și împingem ramura master în portbagajul SVN al plug-in-ului.
În primul rând, dorim să ne întoarcem la ramura Master:
Git comandă comandă
Apoi squash și fuzionați modificările ramura de lucru în master:
git merg --squash de lucru
Dacă s-ar fi făcut schimbări în ramura master, pot exista conflicte în fuzionare. Veți fi invitat să rezolvați manual aceste conflicte înainte ca fuzionarea să se finalizeze. Odată fuzionat, comiteți modificările (această comitet va conține toate comitetele din cadrul departamentului nostru de lucru):
git commit -a -m "a făcut modificări a, b, c, d"
În cele din urmă, ștergem ramura de lucru
git branch -D work
Dacă aveți mai multe filiale pe care doriți să le îmbinați, puteți face acest lucru pentru fiecare dintre ele. Există metode alternative, pe care nu le voi acoperi, ale aplatizării istoriei (cum ar fi rebalizarea interactivă).
În acest moment ați putea, dacă v-ați dorit, să vă împingeți ultimele modificări în contul dvs. GitHub:
git push -u maestru de origine
Pentru a împinge la depozitul WordPress, vă asigurăm mai întâi că depozitul nostru local este "actualizat":
git svn rebase
Git va merge apoi să vă aducă depozitul de subversiune și să fuzioneze orice schimbări acolo cu schimbările pe care le-am făcut. În mod normal, nu ar trebui să existe modificări în depozitul WordPress, așa că ar trebui să vedeți mesajul: Managerul de ramură actual este actualizat.
Acum ne putem împinge schimbările în depozitul WordPress
git svn dcommit
Git vă poate solicita apoi acreditările WordPress.org. Odată introduse modificările vor fi angajate în depozitul WordPress. La scurt timp, ar trebui să primiți un e-mail din depozitul WordPress, informându-vă despre comitete.
În prezent, aceste modificări vor sta în portbagaj. Ce se întâmplă dacă vrem să etichetăm o nouă versiune a plug-in-ului nostru? Când creați următoarea versiune pentru plug-in-ul dvs., ar fi trebuit să actualizați fișierul ReadMe, astfel încât eticheta stabilă să indice noua versiune (spune "2.0"). De asemenea, ar trebui să actualizați informațiile din antetul plug-in-ului dvs. în dvs. de plug-in-name.php fişier. Dacă ați uitat să faceți acest lucru, trebuie doar să treceți prin procedura de mai sus, după efectuarea acestor modificări.
Odată ce "trunchiul" dvs. este pe deplin actualizat (inclusiv cele mai recente informații despre versiune), atunci pur și simplu trebuie să creați noua etichetă în depozitul WordPress:
git svn tag "2.0"
Aceasta copiază totul în trunchi tag / 2.0 (ceea ce obții în mod normal în SVN cu svn cp tag-uri trunk / 2.0).
Dacă doriți să etichetați versiunea în depozitul local:
git tag -a 2.0-m "Tagging 2.0"
Similar cu ceea ce am făcut cu depozitul WordPress, asigurați-vă că depozitele noastre sunt de acord, apoi împingeți schimbările și etichetele noastre:
git trage --rebase origine maestru git împinge origine maestru git push origin --tags
În cele din urmă, există câteva foi de înșelătorie ale lui Git, care pot fi utile: aici și aici.
Accentsconagua