5102077444

5 ORGANIZACJA PRACY -GIT

Jak już wspomniano we wstępie, kolaboracja nad projektem była wspierana przez system kontroli wersji Git. Repozytorium postanowiono zorganizować zgodnie z ogólnie przyjętym schematem „workflowu". Zakłada on występowanie kilku odseparowanych „ścieżek rozwoju", gałęzi (ang. branch):

•    master - tutaj pojawiają się tylko stabilne wersje programu, gotowe do udostępnienia,

•    develop - wersje stabilne, ale jeszcze nie przetestowane,

•    feature - gałęzie o skończonym czasie istnienia, rozwijane są w nich odseparowane funkcje programu.

• Unlimlted lifespan

DEVELOP FEATURE A FEATURE B FEATURE C

branch

•    Stable codę

•    Tagged verslon numbers

•    Branched from oevelop

•    Merged into DEVELOP

• Merged into DEVELOP and MASTER

http://www.marvinlabs.com/2013/06/18/our-eit-workflow-cheatsheet/

Zdalne repozytorium przechowywane było na serwerze GitHub. Jako iż projekt był stosunkowo niewielki i uczestniczyło w nim tylko dwóch kolaborantów, pojawiły się jedynie dwie gałęzie typu feature i dwie wersje stabilne.

Na następnej stronie zamieszczono graf przepływu pracy. Widać na nim wyraźnie dwie równoległe gałęzie master (niebieska) i develop (różowa) oraz odchodzące z niej dwie funkcje (filoletowa i zielona). W pewnym momencie pojawia się też gałąź gh-pages (żółta), której istnienie wyjaśniono w następnym rozdziale. Graf wygląda niemal podręcznikowo.

W związku z tym, że było to pierwsze zetknięcie się autorów z taką organizacją Gita, to niestety komentarze do niektórych commitów pozostawiają wiele do życzenia.

16