Share
Hvis du har en plug-in som er vert på WordPress-depotet, vil du være ganske kjent med SVN og noen av kommandoene. I denne veiledningen vil jeg vise deg hvordan du kan bruke Git, et annet versjonskontrollsystem populært av GitHub, for å publisere og vedlikeholde plugin-modulen din.
Git og SVN er begge eksempler på Version Control Systems. WordPress 'repository bruker sistnevnte (hvis du har en plugin hosted på WordPress, vil du være kjent med' innsjekk 'for å gjøre endringer i dette lagringsstedet). De begge tillater deg å spore endringer i koden din, men det er store forskjeller mellom dem på hvordan de gjør dette.
SVN er avhengig av et enkelt "sentralt lager" av koden (i vår sammenheng: WordPress plug-in repository). Hver gang du vil redigere plugin-modulen din, må du lage en lokal kopi, foreta endringene, og deretter "sjekke inn" disse endringene til WordPress-depotet.
Git er et desentralisert versjonskontrollsystem. I stedet for å ha bare en lokal kopi av plugin-modulen din, har du en hel klone av plug-in-depotet ditt, komplett med alle endringene. Lageret eksisterer nå i sin egen rett på datamaskinen din. Du kan begå og spore endringer, tilbakestille endringer eller "grense" plugin-modulen din i forskjellige retninger alt på din lokale datamaskin. Bare når du er glad for å oppdatere plugin-modulen, skyver du deretter endringene dine i WordPress-depotet for å gjøre dem offentlige.
I denne opplæringen antar jeg at du har en plug-in som er vert på WordPress-plugin-lageret, eller i det minste har du fått din hostingforespørsel godkjent. Hvis du ikke er sikker på hvordan du får plugin-modulen din hostet av WordPress, foreslår jeg at du leser vår artikkel om hvordan du publiserer til WordPress plugin-depotet.
Det er mange argumenter for og imot å bruke Git over SVN (samt decentraliserte versjonskontrollsystemer generelt). Mange av disse stammer fra de fundamentalt forskjellige måtene Git og SVN sporer endringer. En utmerket, grundig analyse av Git og SVN finnes i CodeForests Git vs SVN-artikkel, men for WordPress-utvikleren:
En ulempe med å bruke Git, får det til å fungere fint med et SVN-lager. Det er egentlig ikke så vanskelig takk til git svn, og denne artikkelen er her for å veilede deg gjennom den.
Hvis du ikke allerede har det, vil du installere Git. Hvordan installere Git er dekket ganske bra i Git Community-boken og Pro Git-boken (begge utmerket ressurser hvis du er ny til Git). Hvordan installere Git vil avhenge av operativsystemet ditt, så vil hvilke GUI-programmer som er tilgjengelige for deg. I denne opplæringen skal jeg gjøre alt gjennom kommandolinjen - og jeg oppfordrer deg til å gjøre det samme. På slutten av artikkelen vil jeg foreslå noen GUI-programmer du kan bruke, men vanligvis bruker jeg dem bare til å visualisere filialens grener.
Som tidligere nevnt, med Git, kan du ikke sjekke ut en kopi av plugin-modulen. Du klonerer depotet, komplett med en historie om endringene, og alle grenene og kodene. Trinn 1 er så å klone plug-inens WordPress-vertsregister. Som et eksempel vil jeg publisere en plugin for Post Type Archives Link basert på en tidligere opplæring. Så (når du har blitt akseptert på WordPress-depotet) åpner du kommandolinjegrensesnittet, og naviger til hvor du vil lagre den lokale versjonen av plugin-modulen din. Jeg skal legge den inn i en mappe som heter 'plugins'. En gang der vil vi fortelle Git hvor du finner vår plugin. På tidspunktet for skrivingen er det nesten 20 000 plugin-moduler som er vert i WordPress-depotet, og over 500 000 revisjoner. Vi ønsker ikke å vente på Git å tråle gjennom hver av dem for å finne plugin-modulen vår. Så først og fremst finner vi hvilken revisjon vår plugin starter på (vi vil ha hele historien). For å gjøre dette får vi den første loggen av plugin-modulen din (når den ble opprinnelig lagt til i depotet):
svn log -r 1: HEAD - limit 1 http://plugins.svn.wordpress.org/your-plug-in-name
Det vil tenke en stund, og da bør du se noe slikt:
r520657 | plugin-master | 2012-03-19 03:56:31 +0000 (ma, 19 mars 2012) | 1 linje
Det første nummeret, '520657' for min plugin, er den første revisjonen. Vi bruker den i kommandoen som forteller Git å klone vår plugin-historie. Erstatt XXXXXX med revisjonsnummeret ditt.
git svn klone -s -rXXXXXX - no-minimize-url http://plugins.svn.wordpress.org/your-plug-in-name cd din-plugin-navn git svn hente git svn rebase
'-s'forteller Git å forvente standard (Tag, Trunk, Branches) layout av et SVN repository. '--no-minimal-url'stopper det ser ut av plugin-mappen din. Pass på at den ikke mangler. Hvis du forlater det, kan du ende opp med å kopiere hele WordPress-plugin-depotet. De -rXXXXXX forteller Git hvilken revisjon å se etter. Hvis du forlater det, vil Git søke gjennom hele historien til depotet. Det er over 500 000 revisjoner. Jeg forlot dette en gang, og det tok omtrent to timer. Med det inn, bør det bare ta noen minutter.
Når det er gjort, bør du oppdage at det er opprettet en mappe som heter 'your-plug-in-navn'i' Plugins '-mappen din. La oss utforske litt. Naviger til 'your-plug-in-navn'mappe og kjør en kommando for å se hva' grener 'eksisterer:
git grenen -a
Dette vil liste alle grener, lokalt og eksternt. Den eneste lokale grenen skal være Master (stjernen angir at dette er grenen du er på). Den andre grenen er "stammen", og hvis du har noen, en gren for hver tag (SVN behandler tagger som grener, men Git er litt smartere enn det).
Kommer til din lokale mappe,plugins / din-plugin-navn', bør du se plugin-filene dine (hvis det var noen). Før du lager eller redigerer filer der inne, skal vi lage en egen avdeling for å jobbe med.
Oppdater: Kommandoene ovenfor har blitt oppdatert på grunn av et problem nevnt i kommentarene nedenfor av Neerav og John Eckman. Koden ovenfor reflekterer nå Stephen Harris anbefaling.
En av fordelene ved å bruke Git er at du enkelt kan vedlikeholde en versjon av plugin-modulen din på GitHub. Dette gjør plugin-modulen din mer tilgjengelig for andre utviklere, som kan foreslå forbedringer eller til og med lage egne modifikasjoner som du kan trekke inn i ditt eget arkiv. Hvis du allerede er konfigurert med GitHub, kan du på dette tidspunktet trykke på plugin-modulen din på kontoen din. For å gjøre det, må du først opprette et nytt lager på GitHub-kontoen din, og legg deretter til dette som en ekstern filial til ditt lokale lager:
git remote add opprinnelse [email protected]:/ .git
'ditt brukernavn'refererer til ditt GitHub brukernavn og'your-repo-navn'refererer til navnet på depotet du har opprettet på GitHub. Deretter skyver du bare ditt lokale lager:
git push origin master
Vi skal skape en ny grenen 'arbeid'. Det er innenfor denne grenen at vi skal endre plugin-modulen, gjøre endringer og legge til funksjoner etc. Dette betyr at vår "Master" -avdeling holdes i sin opprinnelige tilstand. Dette gjør at vi kan bytte tilbake til hovedgrenen, og avgrene igjen. Anta at det er en stor feil i plugin-modulen mens du jobber med noen nye funksjoner i arbeidsgrenen. Du kan bytte tilbake til "master" -grenen din (som ikke inneholder noen av funksjonene du arbeider for tiden), forplikte seg til feilen og deretter skyve den til WordPress-depotet. Du kan da bytte tilbake til arbeidsgrenen din og fortsette hvor du sluttet. (Merk: Git lager ikke kopier av filene dine - det vil alltid være bare ett sett med filer i din lokale mappe. Hva disse filene inneholder vil avhenge av hvilken filial du er på.)
Faktisk er det en god ide å lage en grense for hver ny funksjon du legger til plugin-modulen din. Når du er ferdig, slår du bare sammen disse tilbake i hovedgrenen. Hvis dette forårsaker noen "konflikter", blir du bedt om å løse disse manuelt.
Først opprett en filial kalt 'arbeid':
git grenen arbeid
Deretter 'sjekk ut' (gå til) gren 'arbeid':
git checkout arbeid
En melding vil fortelle deg at du har byttet til arbeidsavdelingen. Bruk din favoritt tekstredigerer til å åpne filene dine i din lokale mappe (eller opprett dem hvis det ikke er noen ennå). Når du har gjort noen, vil du kanskje se hvilke filer du har endret. Du gjør dette med den enkle kommandoen:
git status
Dette vil liste endringer av spores og untracked filer. Det kan være filer du ikke vil at Git skal plage sporing (for eksempel midlertidige filer), men hvis du har lagt til noen nye filer i mappen, må du fortelle Git å spore dem. Du kan gjøre dette med kommandoen:
git add
Jeg har opprettet to filer 'post-type-arkiv-links.php'og'metabox.js'i min lokale mappe, så jeg har lagt dem til å fortelle Git å spore dem. Du må sørge for at du sporer din readme fil.
Du kan også se endringene siden siste forlovet (dette er hvor et GUI-program blir veldig nyttig)
git diff
Når du vil forplikte endringene til ditt lokale lager:
git commit -a -m "Gikk abc til xyz"
å gi en (detaljert) melding om endringene i commit.
I ferd med å gjøre endringer kan du (og burde) begå så ofte som mulig - men på en logisk måte, helst med en forpliktelse for hver ting du gjør. Du bør sørge for at det ikke er noen åpenbare feil i dine forpliktelser heller. Å fortryde en forpliktelse er rask og smertefri: Du gjør dette ved å utføre en annen forpliktelse som reverserer den forrige:
Git tilbake HOVED
(Du blir bedt om en melding for å beskrive dette forpliktelsen.)
Anta at du nå er i en posisjon der du vil presse alle endringene dine til SVN-depotet. Før du gjør dette, må vi bare ha noe i tankene. Git oppfordrer deg til å begå seg ofte, og det er god praksis å gjøre det ... for utvikling. Imidlertid er ditt WordPress plug-in repository der for fordeling. Det trenger ikke hver eneste forpliktelse. Faktisk, det gjør det egentlig ikke vil det heller, som Otto (WordPress-kjernebidragsyter) advarer:
"Hvis jeg tar deg til det [skyver hver forpliktelse separat], så vil jeg forby deg fra WordPress.org. SVN trenger bare din endelige arbeidsversjon forpliktet til det, ikke hele historien om de hundrevis av endringer du har gjort ved hjelp av Git. Flatt endringene dine til en enkelt forpliktelse. "
For å unngå dette, når vi er klare til å presse til WordPress-depotet, fusjonerer vi alle forpliktelsene til en forpliktelse. Det er et par måter å gjøre dette på. Vi skal fusjonere (og samtidig squash) våre endringer fra vår arbeidsgren til vår hovedgren. Da vises alle våre endringer som en forplikter seg på hovedgrenen. Vi sletter deretter arbeidsgrenen og skyver hovedgrenen til vår plugin's SVN-stamme.
Først vil vi bytte tilbake til hovedgrenen:
git checkout mester
Deretter squash og slå sammen arbeidsgrenen endringer i mesteren:
git fusjon - kvitt arbeid
Hvis det var gjort endringer i hovedgrenen, er det kanskje konflikter i sammenslåingen. Du blir bedt om å løse disse konfliktene manuelt før sammenføyningen kan fullføres. Når du har slått sammen, legger du til endringene (denne fordelen vil inneholde alle forpliktelsene fra vår arbeidsgren):
git commit -a -m "Gjort endringer a, b, c, d"
Endelig sletter vi arbeidsgrenen
Git grenen -D arbeid
Hvis du har flere grener du ønsker å slå sammen, kan du gjøre dette for hver av dem. Det finnes alternative metoder, som jeg ikke vil dekke, for å flette din historie (for eksempel interaktiv gjenoppretting).
På dette tidspunktet kan du, hvis du vil, trykke på de nyeste endringene i GitHub-kontoen din:
git push -u origin master
For å presse til WordPress-depotet, sørger vi først for at vårt lokale lager er oppdatert:
git svn rebase
Git vil da gå og hente ditt subversion-depot og slå sammen endringer der med de endringene vi nettopp har gjort. Normalt bør det ikke være noen endringer i WordPress-depotet, så du bør se meldingen: Nåværende grenmester er oppdatert.
Nå kan vi skyve våre endringer til WordPress-depotet
git svn dcommit
Git kan da be deg om dine WordPress.org legitimasjonsbeskrivelser. Når du har skrevet inn, vil endringene dine bli forpliktet til WordPress-depotet. Kort tid bør du motta en e-post fra WordPress-depotet, og informere deg om forpliktelsene.
Foreløpig vil disse endringene sitte i kofferten. Hva om vi vil merke en ny versjon av plugin-modulen vår? Når du lager den neste versjonen for plugin-modulen, bør du ha oppdatert ReadMe-filen, slik at den stabile taggen peker på den nye versjonen din (si "2.0"). Du bør også ha oppdatert informasjon om headerinformasjonen til plugin-modulen i din your-plug-in-name.php fil. Hvis du har glemt å gjøre dette, bare kjør gjennom prosedyren ovenfor, etter å ha gjort disse endringene.
Når "stammen" er fullstendig oppdatert (inkludert den nyeste versjonen), trenger vi bare å lage den nye taggen i WordPress-depotet:
git svn tag "2.0"
Dette kopierer alt i bagasjerommet til tags / 2.0 (hva du vanligvis oppnår i SVN med svn cp trunk tags / 2.0).
Hvis du ønsket å merke utgivelsen i ditt lokale lager:
git tag -a 2,0-m "Tagging 2.0"
Ligner på hva vi gjorde med WordPress-depotet, sørg for at våre arkiver er enige, og trykk deretter på endringene og kodene våre:
git pull --rebase opprinnelse master git push opprinnelse master git push opprinnelse - tags
Til slutt er det et par Git 'cheat sheets' som kan komme til nytte: her og her.
Accentsconagua