Гит (5. део): Организација
Аутор: Златан Васовић
Лако можемо направити Git програмско складиште и мењати кôд, али да ли смо се икада запитали, какву организацију кôда имамо? Организација је потребна да бисмо лакше развијали пројекте и да би корисници могли лако да нађу оно што им је потребно.
Развојне гране
Када смо причали о Git терминологији, поменули смо и развојне гране. Оне су веома битне за развој. Master је главна развојна грана. Сви commit-и са осталих развојних грана на крају долазе до њега. Нестабилним верзијама није место на master-у, јер он служи само за стабилне верзије програма. Development је нешто слично trunk-у у Bazaar-у. Он је стална развојна грана. Врло често су верзије програма које се налазе на њему веома нестабилне. Када програм дође до нове стабилне верзије, онда она одлази на master. Постоје и алтернативе за development, као што су: RC (Release Candidate), alpha, beta и WIP (Work In Progress). Једина разлика је начин развоја, који је описан у 3. делу овог серијала. Разне алатке које чине програм могу такође бити на посебној развојној грани.
Ознаке
Требало би да свака верзија буде означена, како би корисници могли да преузму одређену верзију програма. Означене верзије не морају бити увек стабилне, ту могу доћи и нестабилне верзије као што је beta. Верзије се означавају само када су завршене. Треба избегавати називе ознака као што су first version (прво издање), alpha, beta и сличне, јер тада корисник не може да сазна за коју је то верзију ознака. Ознаке могу садржати назив програма у облику <наш програм> x.y.z.
Кôд
Кôд наравно треба бити организован, док умањене (енгл. minified) верзије датотека треба остављати само ако је то неопходно. Упутства о организацији кôда у неком језику можете пронаћи на интернету. На GitHub-у се налази одлично упутство за CSS, HTML, JS и Ruby [1].
Документација
Често постоје нејасноће око коришћења програма. Зато је препоручљиво направити wiki или сајт на коме ће се налазити документација. Уколико не можете да направите сајт, онда само у подешавањима програмског складишта укључите wiki опцију. Документација треба да садржи ЧПП (FAQ) – често постављана питања, упутства за инсталацију и почетно подешавање (setup).
Issue tracker
Issue tracker служи за праћење проблема корисника (укључујући и аутора). Процедура је једноставна – укључите Issues опцију у подешавањима програмског складишта.
Најбитније је подесити ознаке (labels). Оне за један класичан програм могу изгледати овако:
-
bug – грешке у кôду
-
feature – захтеви за додавање нечега што недостаје програму
-
help – нејасноће при коришћењу програма
-
wontfix – нешто неизводљиво или већ исправљено, па је онда непотребно решавати такве проблеме.
Milestone-ови представљају наредне верзије које треба да садрже исправке одређених проблема. Организују се по називу верзије. Назив milestone-а треба да буде у x.y.z облику.
Користан линк: