@mk321: u nas to wygląda tak -> duzy task oho ktos cos zrypal, i zle opisal albo nie mial na to czasu. wiec trzeba zrobic dekompozycje. na mniejsze zadania. Taski wyceniamy na podstawie wag. wagi to kolejne elementy ciągu fibonaciego.

Zadania nie powinny miec wagi wiekszej niz 3 co oznacza ze jest sie w stanie zrobic to ponizej pol dnia roboczego. Wszystko powyzej 3 powinno byc zdekomponowane na mniejsze taski i podpiete jako related issue.

każde issue(task) to osobny Merge reqest i cr. i tyle. Dbamy o to by w gitlabie nie pojawialy sie taski których nie jestes w stanie zrobic w pol dnia. jezeli jest za duze trzeba je zdekomponować i tyle. jeden task moze miec xPokaż całość

@globalbus: co do tego kiedy ma wejsc na proda dla biznesu -> feature togle polecam. wlaczasz / wylaczasz danego featura kliknieciem. a kod przed wlaczeniem moze sobie lezec nawet i pol roku na prodze w oczekiwaniu az biznes bedzie potrzebowal tego.

@mk321: Poczytaj o submodułach (https://git-scm.com/book/en/v2/Git-Tools-Submodules)

@mk321: możecie też inaczej pracować z branchami, np. w obu repozytoriach tworzyć branche feature'owe, a po review równocześnie je mergować. Wtedy na głównej gałęzi zawsze działający kod.

@ksiak: w projektach mam ostatnio głównie github, gitlab czasem bitbucket

@gabonczyk ja mam git+gerrit ale cóż. Wszystko stoi na serwerach firmy, przygotowane na tip top od lat. Dev support mocno rozbudowany. Korzysta się z tego super wygodnie.

@wuut imho nie warto w gerricie robić takich setów. Lepiej squash. Sam gerrit trzyma różnice między patchsetami więc o tak nie ma problemu. W razie czego można się wycofać normalnie.

Ze znajomymi piszemy aplikację w ramach nauki.

przez kilka lat

@mk321: Tak będzie xD

wolałbym nie używać mechanizmów code review na Bitbucket

Pokaż całość

@mk321 jak dobrze pamiętam to nie. Były jakieś dziwaczne opcje, oauthy, openID czy cuda wianki i to się okazało najprostsze

Nie chcę używać "pull requestów" z Bitbucketa (bo uzależnię się od niego, chciałbym w każdej chwili móc przesiąść się na Githuba/Gitlab)

@mk321: Trochę za poważnie to traktujesz, przestawienie się na inny system PRów to MAX kilka dni. Używałem kilku różnych systemów i nie ma co się tym tak przejmować. Użyjcie po prostu bitbucketa albo githuba (też już są darmo prywatne repa dla kilku kolaborantów).

@mk321:

Z tego co słyszałem, to ja mam się martwić mergem

dziwne, moze masz zmergowac swoj branch z masterem najpierw?

zapytaj lepiej, bo cos tutaj nie gra

@mk321: No merge nie jest fast-forward więc po prostu kliknij enter. O to czy używać pull --rebase pytaj swojego przełożonego.

@Septiusz: gerrit jest czytelniejszy imo, i ma tez inna troche zasade dzialania - oparty byl u mnie przynajmniej na rebase, a nie wystawianiu PR. jest tez znacznie szybszy.

@Septiusz: jesli chcesz robic gerrita dla firmy mniejszej niz paredziesiat osob to moga byc z tym problemy. tzn. bardzije sie oplaca trzymac ten szajs CI na zewnatrz.

@bogobojny_trans Zobacz sobie jeszcze SonarQube. Dość solidny system i spotykany w komercyjnym programowaniu. Jest nawet chyba opcja używania online w przeglądarce. Może z tym coś się uda. :)

@player11one tak w jenkinsie mozesz robic co chcesz. Odpalac testy, generowac raporty itp. Kwestia konfiguracji