četvrtak, 26 decembra, 2024
Sam svoj majstor

Git (5. deo): Organizacija

Autor: Zlatan Vasović

Lako možemo napraviti Git programsko skladište i menjati kôd, ali da li smo se ikada zapitali, kakvu organizaciju kôda imamo? Organizacija je potrebna da bismo lakše razvijali projekte i da bi korisnici mogli lako da nađu ono što im je potrebno.

Razvojne grane

Kada smo pričali o Git terminologiji, pomenuli smo i razvojne grane. One su veoma bitne za razvoj. Master je glavna razvojna grana. Svi commit-i sa ostalih razvojnih grana na kraju dolaze do njega. Nestabilnim verzijama nije mesto na master-u, jer on služi samo za stabilne verzije programa. Development je nešto slično trunk-u u Bazaar-u. On je stalna razvojna grana. Vrlo često su verzije programa koje se nalaze na njemu veoma nestabilne. Kada program dođe do nove stabilne verzije, onda ona odlazi na master. Postoje i alternative za development, kao što su: RC (Release Candidate), alpha, beta i WIP (Work In Progress). Jedina razlika je način razvoja, koji je opisan u 3. delu ovog serijala. Razne alatke koje čine program mogu takođe biti na posebnoj razvojnoj grani.

Oznake

Trebalo bi da svaka verzija bude označena, kako bi korisnici mogli da preuzmu određenu verziju programa. Označene verzije ne moraju biti uvek stabilne, tu mogu doći i nestabilne verzije kao što je beta. Verzije se označavaju samo kada su završene. Treba izbegavati nazive oznaka kao što su first version (prvo izdanje), alpha, beta i slične, jer tada korisnik ne može da sazna za koju je to verziju oznaka. Oznake mogu sadržati naziv programa u obliku x.y.z.

Kôd

Kôd naravno treba biti organizovan, dok umanjene (engl. minified) verzije datoteka treba ostavljati samo ako je to neophodno. Uputstva o organizaciji kôda u nekom jeziku možete pronaći na internetu. Na GitHub-u se nalazi odlično uputstvo za CSS, HTML, JS i Ruby [1].

Dokumentacija

Često postoje nejasnoće oko korišćenja programa. Zato je preporučljivo napraviti wiki ili sajt na kome će se nalaziti dokumentacija. Ukoliko ne možete da napravite sajt, onda samo u podešavanjima programskog skladišta uključite wiki opciju. Dokumentacija treba da sadrži ČPP (FAQ) – često postavljana pitanja, uputstva za instalaciju i početno podešavanje (setup).

Issue tracker

Issue tracker služi za praćenje problema korisnika (uključujući i autora). Procedura je jednostavna – uključite Issues opciju u podešavanjima programskog skladišta.

Najbitnije je podesiti oznake (labels). One za jedan klasičan program mogu izgledati ovako:

  1. bug – greške u kôdu
  2. feature – zahtevi za dodavanje nečega što nedostaje programu
  3. help – nejasnoće pri korišćenju programa
  4. wontfix – nešto neizvodljivo ili već ispravljeno, pa je onda nepotrebno rešavati takve probleme.

Milestone-ovi predstavljaju naredne verzije koje treba da sadrže ispravke određenih problema. Organizuju se po nazivu verzije. Naziv milestone-a treba da bude u x.y.z obliku.

Prethodni deo | Nastavak

Koristan link:

[1] https://github.com/styleguide