Kako da povežete GitHub i WordPress
Ako ste iskusniji web developer, kreiranje web sajta može da se čini gotovo rutinskim poslom, sve dok ne dođete do nekog složenijeg projekta. Recimo da vam je klijent tražio da mu uradite sajt koji se sastoji iz stotina stranica i pritom treba da obuhvati mnogo različitih funkcionalnosti.
Verovatno je da takav projekat nećete moći da realizujete sami, već će vam biti potrebno nekoliko developera koji će vam priskočiti u pomoć.
Ovakva vrsta projekata obično zahteva da timovi developera rade na istoj bazi koda, gde svako ima pristup kodu na kojem se radi i mogućnost da prati izmene na tom kodu. Tu nam u pomoć dolazi GitHub.
S obzirom da se na našem blogu najčešće bavimo temama koje se odnose na WordPress, u ovom tekstu ćemo objasniti kako da integrišete GitHub i WordPress.
Inače, sve što budete pročitali možete da primenite i na bilo koji drugi projekat koji ne mora da ima veze sa WordPress-om.
Šta je GitHub?
Git vam omogućava da modifikujete kod i istovremeno čuvate istoriju svih izmena na vašem računaru. Sa druge strane, GitHub je, kako mu i samo ime sugeriše, neka vrsta hub-a za vaše online repozitorujume.
GitHub možete da koristite da:
Obezbedite modifikacije svog koda – GitHub vam omogućava da uvek možete lako da se vratite na tačku gde su napravljene određene izmene u kodu
Spojite kod na kojem radi više developera – Ukoliko radite u timu, GitHub će vam pomoći da organizujete vaš rad i ne pregazite rad drugih developera dok radite u istim fajlovima.
Imate različite grane razvoja – Ovo je kao da imate različite verzije istog proizvoda. Možda ste razvili granu za funkcionalnost na kojoj trenutno radite i imate posebnu granu na kojoj se nalaze već testirane funkcionalnosti koje su već spuštene na produkciju.
Čuva vaš kod na udaljenoj lokaciji – Ovo je ujedno jedna od najboljih stvari vezano za GitHub. Možete lako da sarađujete sa ostalim članovima tima i budete sigurni da je vaš rad sačuvan na pouzdanom mestu i dostupan sa bilo koje tačke na svetu.
Zašto bi trebalo da koristite GitHub sa WordPress-om?
Razvoj WordPress-a se uglavnom sastoji od dva osnovna dela: tema i plugin-a.
Teme vam daju mogućnost da kontrolišete kako vaš web sajt prezentuje sadržaj korisnicima.
Plugini daju vašem sajtu dodatne funkcionalnosti i mogu da se koriste sa različitim temama ili projektima.
Za oba ova tipa razvoja WordPress aplikacija, potrebno je da čuvamo kod i radimo njegova ažuriranja. Tu stupa na scenu GitHub, odnosno tu dolaze do izražaja njegove funkcionalnosti koje mogu pomoći da lakše radite na svom novom WordPress projektu.
Takođe, GitHub nudi mogućnost da preko GiHub Actions automatski primenite bilo koje izmene u vašem repozitorijumu na web server. To vam može pomoći da ubrzate razvojni proces i učinite ga mnogo pouzdanijim.
Kako da podesite GitHub za WordPress?
Pratite sledeće korake za postizanje pouzdanih rezultata. Ukoliko već imati GitHub nalog ili ste neke od ovih koraka uradili već ranije, samo ih preskočite i pomerite se na sledeći.
Kreirajte GitHub repozitorijum
1.1 Idite na https://github.com
1.2. Kliknite na dugme Sign up u gornjem desnom uglu.
1.3 Upišite svoju email adresu i kreirajte password.
1.4. Nakon što ste kreirali nalog, dobićete potvrdni email od GitHub-a sa kodom za prijavu. Kopirajte taj kod i zalepite ga u odgovarajuće polje da potvrdite svoju email adresu.
1.5. Kliknite na Skip personalization ukoliko ne želite da ostavljate GitHub-u podatke o vama ili vašoj kompaniji. To ni u jednom delu neće uticati na funkcionalnost vašeg web sajta i prvenstveno je namenjeno tome da drugi korisnici vide informacije o vama.
1.6. To je sve što se tiče naloga. Kada se ulogujete, kliknite na dugme Create repository iz levog sidebar-a.
1.7. Na sledećem ekranu treba da unesete naziv repozitorijuma. Obratite pažnju da je označen radio button pod nazivom Private. Ostale opcije možete slobodno da ostavite takvim kakve jesu. Zatim pritisnite dugme Create repository.
1.8. Da biste omogućili opciju da sa GitHubom komunicirate sa vašeg lokalnog računara. klonirate repozitorijum ili push-ujete izmene, potrebno je da konfigurišete SSH ključ u GitHub podešavanju. Idite na vaš profil i kliknite na avatar u gornjem desnom uglu, a zatim kliknite na Settings.
1.9. Sada unutar opcije SSH and GPG keys kliknite na dugme New SSH key.
1.10. Dodajte svoj javni SSH ključ na sledeći ekran. Možete da izaberete bilo koji Title.
1.11. Ostavite opciju Key type kao Authentication key. Ukoliko ne možete da pronađete svoj SSH ključ, vrlo je verovatno da ga ni nemate generisanog na svom lokalnom računaru.
Ako ne znate kako da kreirate SHH ključ pročitajte naše detaljno uputstvo Kako da konfigurišete SSH ključeve putem cPanel-a.
Upload-ujte fajlove projekta na repozitorijum
Predlažemo da u repozitorijum dodate samo vašu temu, ne i ceo projekat. Na taj način nećete morati da brinete o ažuriranju WordPress-a.
Evo kako.
2.1. Prebacite svoj radni direktorijum u vašu temu u konzoli/terminalu
cd path/to/your/theme2.2. Otvorite stranicu sa svojim repozitorijumom u GitHub-u. Pratite instrukcije koje GitHub predlaže na toj stranici. Ne zaboravite da koristite SSH.
2.3. Sada imate sve fajlove vaše teme u GitHub repozotorijumu. Nastavite da radite na projektu i regularno commit-ujete i push-jete svoje izmene. Naša preporuka je da to radite na dnevnom nivou.
Podesite GitHub Actions da automatizujete radne tokove
GitHub actions je GitHub-ova alat za automatizaciju, koji omogućava developer-ima da automatizuju svoje radne tokove direktno unutar njihovih GitHub repozitorijuma.
To znači da možete da uradite i neki dodatni posao na vašem kodu, kada on stigne u repozitorijum. To može biti verifikacija koda, upravljanje zavisnostima i mnoge druge stvari.
Jedna od najkorisnijih funkcionalnosti GitHub Actions-a je takozvani auto-deployment. Ako podesite ovu funkcionalnost, svaki put kada je novi kod push-ovan na GitHub repozitorijum, on se automatski objavljuje na vašem WordPress hosting serveru.
Da biste konfigurisali ovu funkcionalnost, potrebno je da dodate folder .github/workflows u vaš projekat i unutra kreirate .yml fajlove.
Evo jednog primera fajla od kog možete da počnete. Naziv nije bitan, ali biramo imena fajlova u zavisnosti od okruženja u kojem bi kod trebalo da bude implementiran.
dev.ymlname: Deploy to staging
on:
workflow_dispatch:
push:
branches:
- develop
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Use the GITHUB_WORKSPACE environment variable
run: ls -la "${GITHUB_WORKSPACE}"
- name: Set up Node.js
uses: actions/setup-node@v3
with:
node-version: ${{ env.NODE_VERSION }}
cache: 'npm'
- name: yarn, build
run: |
yarn
yarn build
- name: Check if composer.json exists
id: check_files
uses: andstor/file-existence-action@v2
with:
files: 'composer.json'
- name: Get Composer Cache Directory
id: composer-cache
if: steps.check_files.outputs.files_exists == 'true'
run: |
echo "dir=$(composer config cache-files-dir)" >> $GITHUB_OUTPUT
- name: Set up dependency caching for faster installs
uses: actions/cache@v3
if: steps.check_files.outputs.files_exists == 'true'
with:
path: ${{ steps.composer-cache.outputs.dir }}
key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}
restore-keys: |
${{ runner.os }}-composer-
- name: Run composer install if composer.json exists
if: steps.check_files.outputs.files_exists == 'true'
run: composer validate --no-check-publish && composer install --prefer-dist --no-progress
- name: Archive Release
uses: thedoctor0/zip-release@0.7.5
with:
type: 'zip'
filename: 'release.zip'
exclusions: '*.git* /*node_modules/* .editorconfig'
- name: Upload artifact for deployment job
uses: actions/upload-artifact@v3
with:
name: release
path: ./release.zip
deploy:
runs-on: ubuntu-latest
needs: build
environment: stage
env:
DEPLOY_TEMP_DIR: /tmp/${{ github.repository }}-${{ github.run_id }}/
steps:
- name: Download artifact from build job
uses: actions/download-artifact@v3
with:
name: release
- name: List downloaded files
run: ls -la
- name: Output deployment temp directory
run: echo "Deployment temp directory $DEPLOY_TEMP_DIR"
- name: Output target path
run: echo "Deployment target path ${{ vars.TARGET_PATH }}"
- name: Copy file via SCP
uses: appleboy/scp-action@v0.1.4
with:
host: ${{ secrets.SSH_HOST }}
port: ${{ secrets.SSH_PORT }}
username: ${{ secrets.SSH_USER }}
password: ${{ secrets.SSH_PASS }}
source: release.zip
target: ${{ env.DEPLOY_TEMP_DIR }}
- name: ssh-job
uses: nekiro/ssh-job@v1.0.5
with:
host: ${{ secrets.SSH_HOST }}
port: ${{ secrets.SSH_PORT }}
user: ${{ secrets.SSH_USER }}
password: ${{ secrets.SSH_PASS }}
command: |
ls -la ${{ env.DEPLOY_TEMP_DIR }}
rm -rf ${{ vars.TARGET_PATH }}
unzip -o ${{ env.DEPLOY_TEMP_DIR }}/release.zip -d ${{ vars.TARGET_PATH }}
rm -rf ${{ env.DEPLOY_TEMP_DIR }}U ovom fajlu ćete naći nekoliko ključnih komponenti:
Kada započeti implementaciju:
Na početku se nalazi ključna reč on: i nakon nje push: branches: – develop — što znači da, kada god se nešto postavi (push) na granu develop, ovaj skript treba da se pokrene.
Šta raditi tokom implementacije:
Sve pod ključnom rečju jobs: build:. Većina instrukcija može da se ponovo koristi između različitih projekata, jer u suštini govore GitHub-u kako da postavi Nodejs i Composer, instalira zavisnosti i druge stvari.
Obratite pažnju na deo sa nazivom yarn, build, jer je to mesto gde navodite specifične korake za izgradnju vašeg projekta. Ovde je navedeno samo yarn za instalaciju zavisnosti i yarn build za pokretanje izgradnje.
Kako objaviti kod:
Job sa nazivom jobs: deploy: je mesto gde ćete pronaći korake koji daju instrukciju kako da se povežete sa vašim hostingom i gde da kopirate fajlove. Pošto ovaj proces najverovatnije zahteva sigurnu vezu sa vašim hostingom, svi kredencijali su navedeni kroz placeholder-e kao što su ${{ secrets.SSH_KEY }}.
Kredencijali za vašu implementaciju su konfigurisani pod Settings → Secrets and variables → Actions.
Sledeći korak je da kliknete na New repository secret i dodate isti naziv koji imate u vašem konfiguracionom fajlu (placeholder-e koje imamo u dev.yml).
Sve vaše kredencijale čuvajte samo tamo i nikada ih ne dodajte direktno u vaš GitHub repozitorijum. Čak i ako dodate fajl i kasnije ga uklonite, on je i dalje dostupan u Git istoriji, tako da se vaša osetljiva informacija može kasnije otkriti.
Sada ste dodali automatsku implementaciju na vaš Development hosting. Ako imate Staging i druga okruženja, jednostavno napravite različite konfiguracione fajlove za njih (staging.yml, prod.yml) i odredite iz koje grane želite da implementirate promene.
Uvek možete implementirati bilo koju granu na vaš hosting jednostavnim ručnim pokretanjem implementacije, zahvaljujući workflow_dispatch podešavanjima u okviru on: sekcije. Da biste pokrenuli implementaciju:
– Idite na Actions, odaberite vaš radni tok (workflow) i kliknite na Run workflow.
– Odaberite vašu granu i kliknite na Run. Na ovaj način, možete implementirati vašu specifičnu granu na razvojni server radi testiranja — bez potrebe da spajate sa develop granom. Ponekad je korisno imati takvu mogućnost.
Preporučujemo da detaljnije istražite GitHub Actions. Postoji velika biblioteka gotovih konfiguracija za različite tipove tehnologija i zadataka. Što više automatizujete, manje ćete morati da radite sami i manje će biti grešaka u hodu.
Sada kada ste postavili vaš GitHub repozitorijum za WordPress, hajde da vidimo kako da ga najbolje iskoristite.
Neke od najboljih praksi u radu sa GitHub-om podrazumevaju sledeće:
– Izbegavajte konflikte prilikom spajanja koda
– Redovno postavljajte kod
– Uspostavite proces pregleda koda
Kako izbeći konflikte prilikom spajanja (merge conflicts) na GitHub-u?
Konflikt prilikom spajanja nastaje kada želite da spojite promene iz repozitorijuma, ali su lokalni fajlovi na kojima radite već izmenjeni od strane nekog drugog developera.
Većina konflikata se dešava kada promenite jednu liniju koda, ali je istu liniju već izmenio vaš kolega.
Kada Git ima poteškoća da razume koje su promene važnije i kako da ih kombinuje, predlaže vam da ih ručno rešite. Ovo ponekad zahteva značajnu količinu vremena i truda.
Najbolja strategija je da u potpunosti izbegnete konflikte prilikom spajanja.
Zato evo nekih saveta i najboljih praksi:
– Ne radite na istoj stranici ili modulu u isto vreme kada i vaši saradnici. Obavestite sve da ćete početi da radite na određenoj funkcionalnosti i zamolite ih da je ne menjaju.
– Pre nego što počnete bilo koji rad, povucite sve nove promene iz repozitorijuma. Verovatno su vaši saradnici već završili svoj posao i možete bezbedno nastaviti sa modifikacijom istog modula, ali ne zaboravite da unesete njihove promene u vašu granu.
– Nemojte menjati nebitne funkcionalnosti. Ponekad je veoma primamljivo uraditi mali refaktoring koda dok radite na jednom delu koda samo zato što ste primetili problem u drugom delu. Nemojte to raditi, jer postoji velika šansa da neko drugi radi na tome. Barem pitajte da li je u redu da to promenite.
– Podelite vaš kod u male fajlove. Imati nekoliko stotina linija koda je više nego dovoljno za većinu funkcionalnosti. Na taj način smanjujete šanse za modifikaciju istih fajlova na kojima rade vaši saradnici.
Kako uspostaviti praksu redovnog postavljanja koda?
Kao što znate, trebalo bi da redovno postavljate (push) svoj kod u repozitorijum. Idealno bi bilo svakodnevno. Evo i zašto:
– Postavljanje koda u repozitorijum stavlja ga na sigurno mesto. U slučaju hardverskog ili softverskog kvara, uvek lako možete vratiti svoj rad.
– Ceo vaš tim može videti napredak zadatka (razvoja) na transparentan način.
– Moraćete da podelite rad na manje delove koji se mogu završiti, izmeniti i zatim postaviti u istom danu. Ovo je odličan pristup u procesu razvoja softvera jer vam omogućava da postepeno razvijate bilo koju funkcionalnost.
Kako uspostaviti praksu pregleda koda (code review)?
Pregled koda je proces manuelne provere nečijeg koda od strane glavnog developera ili drugih članova tima.
Ciljevi ove provere su:
– Osigurati da se u kodu prate najbolje prakse.
– Sprovesti standarde kodiranja kompanije.
– Naučiti o novoj funkcionalnosti koja se implementira.
– Prijaviti greške u ranoj fazi razvoja.
Vrlo je važno raditi pregled koda pre nego što se kod spoji (merge) u razvojnu granu. To sprečava druge developere da počnu da koriste neprovereni kod. Takođe, neke greške mogu uticati na druge delove projekta i izazvati dodatne greške i druge neželjene efekte.
Najlakši način da uspostavite pregled koda je da usvojite GitFlow-ovu konvenciju imenovanja za vaše grane. Svaki projekat treba da ima main i develop grane.
– Main sadrži kod spreman za produkciju.
– Develop ima razvoj u toku koji se kontinuirano razvija i testira.
– Svaka nova funkcionalnost treba da ima svoju granu sa imenom poput feature/<ime-funkcionalnosti>.
Proces pregleda počinje sa završavanjem rešenja unutar feature/<ime-funkcionalnosti> grane. Zatim, da bi se kod iz ove grane spojio sa develop granom, potrebno je proći pregled koda. Na GitHub-u, ovaj proces se zove Pull Request, što doslovno znači Uzmi moj kod ako ti se sviđa.
Da biste napravili pull request (skraćeno PR), postavite (push) vašu granu u repozitorijum i idite na stranicu Pull requests. Ako ste nedavno postavili vašu granu, GitHub će je najverovatnije prikazati na vrhu stranice.
U ovom slučaju, kliknite na Compare & pull request. U suprotnom, pritisnite New pull request i ručno odaberite vašu granu i gde želite da je spojite.
U svakom slučaju, završićete na stranici za kreiranje pull request-a.
Dok kreirate PR, imajte na umu:
– Naslov PR-a obično se automatski popunjava iz vaše poslednje poruke o komitu. Promenite ga ako ne odražava o čemu se radi u vašem PR-u. Preporučujemo da naslov u stvari bude naziv zadatka.
– U opisu možete ukratko navesti funkcionalnosti koje su implementirane ili druge informacije. GitHub ima mogućnost konfiguracije prilagođenih šablona koji će se koristiti za svaki PR, što vam omogućava da postavite standarde za PR-ove u celoj kompaniji.
– Ispod opisa nalazi se lista svih izmenjenih fajlova. Ovo je prilika da se još jednom uverite da niste slučajno dodali nešto što niste želeli.
Kliknite na Create pull request. Nakon toga, vaš PR je kreiran. Zatim možete:
– Kopirati URL i podeliti ga sa članom tima koji će obaviti pregled koda.
– Dodeliti pregled koda nekome putem Assignee sidebar-a.
Proces pregleda koda sadrži nekoliko koraka. Onaj ko ga pregleda prolazi kroz svaki fajl koji je izmenjen i proverava da li su promene ispravne.
Ako nešto nije u redu, dobra praksa je da ostavi komentar sa objašnjenjem šta nije u redu sa konkretnim kodom.
Nakon što je prvi komentar spreman, treba da kliknete na Start a review. To pokreće proces pregleda. Svi dalji komentari će biti dodati ovom pregledu.
Nakon što završite sa pregledom, pritisnite Finish your review i izaberite da li želite da Approve (odobrite) ili da Request changes (zatražite izmene). Zatim kliknite na Submit review.
Nakon toga, vaš kolega će videti sve komentare i može ili da ispravi probleme ili da započne raspravu o potrebnim izmenama.
Na kraju ovog procesa, kada je sve završeno, ponovo prođite kroz proces pregleda i izaberite Approve nakon pregleda.
Poslednji korak je da zapravo spojite PR.
Zaključak
Kao što ste videli, GitHub omogućava sigurno skladištenje koda, olakšava saradnju među developerima, omogućava rad sa različitim verzijama koda i automatsku implementaciju izmena.
Integracija GitHub-a sa WordPress-om može unaprediti rad na temama i plugin-ovima, pružajući vam mogućnost da lako pratite promene, radite na kodu u timovima i automatizujete procese poput deploy-a.
Da biste maksimalno iskoristili GitHub za WordPress projekte, preporučuje se da pratite najbolje prakse, kao što su redovno postavljanje koda, upotreba GitHub Actions za automatizaciju i uspostavljanje procesa pregleda koda.
Korišćenjem GitHub-a, vaš tim može postati produktivniji i osigurati uspešan razvoj i implementaciju složenih web projekata.
Nenad Mihajlović