Această secțiune vă arată cum să începeți lucrul cu depozitul GIT al QGIS. Înainte de a face acest lucru, trebuie să aveți un client git instalat pe sistemul dumneavoastră.
Utilizatorii distribuției Debian pot efectua:
sudo apt-get install git
Windows users can obtain msys git or use git distributed with cygwin.
The git project has a downloadable build of git. Make sure to get the package matching your processor (x86_64 most likely, only the first Intel Macs need the i386 package).
O dată descărcat, deschideți imaginea discului și executați programul de instalare.
Notă PPC/sursă
Site-ul Git nu oferă compilații PPC. În cazul în care trebuie să construiți o compilație PPC, sau doriți doar ceva mai mult control asupra instalării, trebuie să efectuați singuri compilarea.
Download the source from http://git-scm.com/. Unzip it, and in a Terminal cd to the source folder, then:
make prefix=/usr/local
sudo make prefix=/usr/local install
Dacă nu aveți nevoie de facilități suplimentare, Perl, Python sau TclTk (GUI), aveți posibilitatea să le dezactivați înainte de a rula comanda make:
export NO_PERL=
export NO_TCLTK=
export NO_PYTHON=
Pentru a selecta o ramură, de exemplu, ramura 2.6.1:
cd QGIS
git fetch
git branch --track origin release-2_6_1
git checkout release-2_6_1
Pentru a selecta ramura master:
cd QGIS
git checkout master
Note
În QGIS păstrăm codul nostru cel mai stabil din ramura versiunii actuale. Ramura master conține codul pentru așa-numita serie de versiuni ‘instabile’. Periodic vom ramifica o versiune pe care o vom stabiliza continuu și în care vom încorpora selectiv noi caracteristici.
Parcurgeți fișierul INSTALL din arborele sursă, pentru instrucțiunile specifice privind construirea versiunilor de dezvoltare.
În cazul în care sunteți interesat în verificarea surselor documentației QGIS:
git clone [email protected]:qgis/QGIS-Documentation.git
Puteți arunca, de asemenea, o privire la fișierele readme incluse în depozitul cu documentație, pentru mai multe informații.
În cazul în care sunteți interesat în verificarea surselor site-ului web QGIS:
git clone [email protected]:qgis/QGIS-Website.git
Puteți arunca, de asemenea, o privire la fișierele readme incluse în depozitul site-ului web, pentru mai multe informații.
Parcurgeți următoarele site-uri pentru informații despre cum putți deveni un maestru GIT.
Complexitatea codului sursă QGIS a crescut considerabil în ultimii ani. Prin urmare, sunt greu de anticipat efectele secundare pe care le va avea adăugarea unei noi funcționalități. În trecut, proiectul QGIS avea cicluri de lansare cu durată mare, deoarece era necesară o cantitate mare de muncă pentru a reface stabilitatea sistemului software, în urma adăugării unor noi caracteristici. Pentru a depăși aceste probleme, QGIS a trecut la un model de dezvoltare în cazul în care noile caracteristici sunt introduse mai întâi în ramurile GIT, și abia apoi are loc fuziunea cu masterul (ramura principală), după ce au fost finisate și au devenit stabile. Această secțiune descrie procedurile de ramificare și de fuzionare din cadrul proiectului QGIS.
Înainte de a începe, postați un anunț pe lista de discuții a dezvoltatorilor, pentru a vedea dacă un alt dezvoltator lucrează deja la aceeași caracteristică. De asemenea, contactați consilierul tehnic al comitetului (PSC) de coordonare a proiectului. În cazul în care noua caracteristică necesită o modificare a arhitecturii QGIS, este necesară o cerere de comentariu (RFC).
Crearea unei ramuri: Creați o nouă ramură GIT, pentru dezvoltarea noii funcțiuni.
git checkout -b newfeature
Acum puteți începe dezvoltarea. Dacă aveți de gând să lucrați intensiv în această ramură, și să lucrați alături de alți dezvoltatori, care să aibă drepturi de scriere în depozitul părinte, puteți urca depozitul dvs. în depozitul oficial al QGIS:
git push origin newfeature
Note
În cazul în care ramura există deja, modificările dvs. vor fi urcate acolo.
Reîncorporați, în mod regulat, în ramura master: Este recomandabil să reintroduceți modificările în ramura master, în mod regulat. Acest lucru face mai ușoară fuziunea ulterioară a ramurii cu masterul. După încorporare trebuie să efectuați git push -f asupra depozitului dvs. derivat.
Note
Niciodată nu efectuați git push -f în depozitul original! Folosiți această comandă numai pentru ramura în care lucrați.
git rebase master
It is also recommended to document the intended changes and the current status of the work on a wiki page.
Când ați terminat cu noua caracteristică și vă mulțumește stabilitatea, faceți un anunț pe lista dezvoltatorilor. Înainte de fuziunea cu masterul, modificările vor fi testate de către dezvoltatori și utilizatori.
Iată câteva indicații care vă vor ajuta să obțineți cu ușurință corecții și solicitări de actualizare pentru proiectele QGIS, facilitându-ne gestionarea corecțiilor.
În general, este mai ușor pentru dezvoltatori dacă trimiteți cereri de actualizare a codului de pe GitHub. Pentru detalii asupra acestui aspect, faceți referire la documentația GitHub pull request.
Dacă faceți o cerere de actualizare vă rugăm să actualizați cu regularitate ramura master din PR, astfel încât un PR să poată actualiza ramura master părinte.
If you are a developer and wish to evaluate the pull request queue, there is a very nice tool that lets you do this from the command line
Vă rugăm să consultați secțiunea de mai jos pentru a ‘obține atenție pentru corecția dvs.’. În general, atunci când trimiteți o cerere PR ar trebui să vă asumați responsabilitatea de a o urmări până la finalizare - să răspundeți la întrebările postate de alți dezvoltatori, să identificați un ‘susținător’ pentru funcționalitatea propusă de dvs., și să transmiteți un memento manierat, uneori, dacă vedeți că PR-ul nu este luat în considerare. Vă rugăm să țineți cont de faptul că proiectul QGIS este condus printr-un efort voluntar, fiind posibil ca oamenii să nu participe instantaneu la PR. Dacă observați că un PR nu beneficiază de atenția pe care o merită, opțiunile de accelerare a aceastuia ar trebui să fie (în ordinea priorității):
Trimiterea unui mesaj în lista de discuții, pentru a ‘populariza’ PR-ul, indicând și cât de bine ar fi dacă ar fi inclus în baza de cod.
Trimiterea unui mesaj persoanei din lista de PR-uri, căreia i-a fost asignată cererea dvs.
Trimiterea unui mesaj lui Marco Hugentobler (care gestionează lista de PR-uri).
Trimiterea unui mesaj comitetului director al proiectului, cerându-le să vă ajute la încorporarea PR-ului în codul de bază.
Creați întotdeauna o ramură pentru o funcționalitate, pornind de la ramura master curentă.
Atunci când codificați ramura pentru o caracteristică, nu “îmbinați” nimic cu acea ramură, ci mai degrabă folosiți comanda rebase, așa cum este descris în punctul următor, pentru a păstra curat istoricul.
Înaintea creării unei cereri de actualizare a codului efectuați git fetch origin și git rebase origin/master (datorită faptului că originea reprezintă remote pentru părinte, efectuați .git/config sau git remote -v | grep github.com/qgis).
Ați putea executa comanda Git rebase, în mod repetat, fără a provoca nici un prejudiciu (atât timp cât singurul scop al ramificării dvs. este de a obține fuzionarea cu ramura master).
Atenție: După rebase trebuie să efectuați git push -f` în depozitul ramificat. DEZVOLTATORI DE BAZĂ: NU FACEȚI ASTA ÎNTR-UN DEPOZIT QGIS PUBLIC!
Pe lângă etichetele comune pe care le puteți adăuga pentru a clasifica PR-urile dvs., există unele speciale, pe care le puteți utiliza pentru a genera automat rapoarte de probleme în depozitul Documentației QGIS, de îndată ce codul dumneavoastră este combinat:
[needs-docs] pentru a aminti creatorilor documentației să ceară adăugarea de informații suplimentare, după corectarea sau îmbunătățirea unei funcționalități existente deja.
[feature] în cazul noilor functionalități. Adăugarea unei bune descrieri PR-ului va reprezenta un bun început.
Rugăm dezvoltatorii să folosească aceste etichete (nu se face diferenţiere între litere mari şi mici), astfel încât creatorii documentației să identifice problemele pe care le au și să aibă o privire de ansamblu asupra lucrurilor de făcut. DAR, faceți-vă, de asemenea, timp pentru a adăuga un text: fie în commit, fie chiar în documentație.
Opţiunea A:
faceți clic pe butonul de îmbinare (Se creează o îmbinare non-fast-forward)
Opţiunea B:
Testare (De asemenea, necesar pentru opțiunea A, evident)
Opțional: git pull --rebase: Creează fast-forward, fără “merge commit”. Istoricul este mai curat, dar este mai greu de anulat îmbinarea.
git push (NICIODATĂ nu folosiți opțiunea -f aici)
If the patch is a fix for a specific bug, please name the file with the bug number in it e.g. bug777fix.patch, and attach it to the original bug report in trac.
If the bug is an enhancement or new feature, its usually a good idea to create a ticket in trac first and then attach your patch.
Procedând în acest mod, aplicarea corecțiilor este mai ușoară, deoarece nu trebuie să navigăm într-un loc specific din arborele sursă pentru aplicarea unei corecții. De asemenea, atunci când primim corecții, de obicei, le vom evalua folosind îmbinarea, iar aplicarea corecției la nivel directorului superior facilitează acest lucru. Mai jos este un exemplu despre cum se pot include în corecție, din directorul de nivel superior, mai multe fișiere modificate:
cd QGIS
git checkout master
git pull origin master
git checkout newfeature
git format-patch master --stdout > bug777fix.patch
Acest lucru vă asigură că ramura master este sincronizată cu depozitul părinte, și apoi generează o corecție care conține diferențele dintre ramura noii funcționalități și ramura master.
QGIS developers are busy folk. We do scan the incoming patches on bug reports but sometimes we miss things. Don’t be offended or alarmed. Try to identify a developer to help you - using the Technical Resources and contact them asking them if they can look at your patch. If you don’t get any response, you can escalate your query to one of the Project Steering Committee members (contact details also available in the Technical Resources).
QGIS este licențiat sub GPL. Ar trebui să depuneți toate eforturile pentru a vă asigura că trimiteți numai corecții care nu sunt grevate de drepturi de proprietate intelectuală, de natură conflictuală. De asemenea, nu trimiteți un cod care nu se încadrează în GPL.
Accesul de scriere în arborele sursei QGIS are loc pe bază de invitație. În mod obișnuit, atunci când o persoană depune mai multe corecții substanțiale (nu există un număr fix), care să demonstreze competența și înțelegerea C++ de bază și a convențiilor de codificare QGIS, unul dintre membrii PSC, sau alți dezvoltatori, pot nominaliza persoana respectivă la acordarea accesului la scriere. Cel care face nominalizarea ar trebui să justifice printr-un paragraf promoțional, motivele pentru care consideră că o persoană ar trebui să aibă acces la scriere. În unele cazuri, vom acorda acces la scriere dezvoltatorilor non C++, de ex. pentru traducători și creatorii de documentație. Chiar și în aceste cazuri, persoanele trebuie să demonstreze o înțelegere a proceselor de modificare a bazei de cod fără producerea de erori, etc.
Note
Din momentul orientării către GIT, suntem mai puțin susceptibili la acordarea accesului de scriere pentru noii dezvoltatori, deoarece este banală partajarea codului din cadrul github, prin bifurcarea QGIS, urmată de emiterea cererilor de actualizare.
Verificați întotdeauna că totul se compilează corect, înaintea efectuării cererilor de actualizare. Încercați să conștientizați posibilele defecțiuni pe care le-ar putea produce actualizările dvs. asupra celor care lucrează pe alte platforme, sau cu versiuni mai vechi/mai noi ale bibliotecilor.
Atunci când se face o actualizare, editorul dvs. va fi indicat (așa cum este definit în variabila de mediu $EDITOR), iar dvs. va trebui să efectuați un comentariu în partea de sus a fișierului (deasupra zonei care spune ‘nu efectuați modificări’). Introduceți un comentariu descriptiv și, mai degrabă, efectuați mai multe mici, în cazul în care modificările dintr-un număr mare de fișiere sunt independene. Pe de altă parte, preferăm să actualizați împreună modificările efectuate în fișiere înrudite.