Każdy projekt posiada swoje repozytorium Git założone na BitBuckecie (user: snowflakers). Wszystkie firmowe repozytoria zawsze muszą być prywatne i przypisane do tego konta.
Każde repo powinno mieć 2 główne branche: master oraz develop. Oba muszą zawsze posiadać taki sam stan pod względem modyfikacji. Muszą być identyczne.
Jeżeli merge’ujesz jakieś zmiany do brancha develop, musi być on niezwłocznie zmerge’owany do master.
Jeżeli jako developer masz za zadanie napisać nową funkcjonalność lub np. poprawić jakiś bug w aplikacji, twórz nowy branch z brancha develop o nazwie z prefiksem develop i pojedynczym podkreślnikiem, np. develop_menu-bug-fix, develop_module-a-development.
W przypadku operacji “pójścia live” ze zmianami, Twój roboczy branch (np. wspomniany develop_menu-bug-fix) powinien być najpierw zmerge’owany do develop, a następnie branch develop do master.
W naszym zespole nie ma obowiązkowego Code Review, nie mniej jednak robimy je często i praktycznie zawsze po zakończeniu danego etapu pracy nad projektem/funkcjonalnością. Kierujemy się zasadą, że kod należy pielęgnować jak ogród – nawet jeśli nie będzie Code Review przed wypuszczeniem funkcjonalności na produkcję, developer, który zauważy po czasie w danym fragmencie kodu problem lub element, który wymaga poprawy – powinien zaproponować poprawkę.
Jako developer, aby poprosić o Code Review, stwórz Pull Request i oznacz inną osobę z Twojego działu, którą chciałbyś poprosić o przejrzenie kodu. PR powinien oznaczać branch develop jako docelowy branch, do którego dany branch ma być zmerge’owany.
Zaznaczaj opcję Close branch podczas tworzenia PR, aby w momencie zmerge’owania brancha, został on usunięty.
Pamiętaj, aby prosić o Code Review rozsądnie – jeśli np. miałeś do poprawy literówkę albo prostą zmianę w interfejsie, co nie spowoduje problemu dla biznesu i która jednocześnie od razu ma się pojawić na produkcji – po prostu działaj i merguj do develop / master! Proś o Code Review, kiedy rzeczywiście wymaga tego sytuacja.
Commitując zmiany, pamiętaj o krótkim, acz treściwym opisie (commit message). Nie chodzi o to, abyś pisał elaborat, ale abyś zwięźle opisał zmiany, z myślą o innych developerach, skupiając się na tym, aby opis był dla nich zrozumiały.
Podczas początkowej fazy projektu nasi front-end developerzy zaczynając projekt samodzielnie, tworzą czasem główny branch frontend, z którego tworzą branche odpowiadające danej funkcjonalności, nad którą pracują. W dalszej fazie developmentu i tak branch frontend jest merge’owany do głownego brancha develop.
Jeżeli nad danym zadaniem będziesz pracował wspólnie z innym członkiem zespołu, dobrze jest zakomunikować nazwę brancha, uzgodnić wcześniej plan (np. o wspólnym merge’owaniu do jednego brancha, na którym znajdzie się zaplanowany zakres funkcjonalności/poprawek).
Kluczem zawsze jest komunikacja!