Mniej bałaganu

• NOWY TASK / NOWE ISSUE = NOWY BRANCH

  • zgodnie z issue rozpisanymi na GitHub
  • jeśli uważacie że jeden task należy rozbić na kilka —> rzucacie temat grupie, rozbijacie task na takie części jakie powinny być w Project na GitHub
  • każdy z nowych isse ma swój własny #numer dla każdego z nich tworzycie nowy branch

• PRACA W TOKU

  • w każdej chwili, na każdym etapie, nawet bardzo początkowym możecie wysyłać swoje lokalne branche na remote (NIE PR, tylko żeby były na gitHub w razie co, w razie żeby ktoś mógł go pobrać żeby pomóc, sprawdzić coś dla siebie, itp), może starajcie się nie wysyłać takich śmieciowych branchy, potrzebnych tylko na chwilę, ale jeśli wyślecie też się nic nie stanie
  • DRAFT - generalnie to też oznacza że wasze Issue jest w trakcie pracy, myślę, że warto wrzucać drafty, kiedy to co robicie zaczyna przypominać realizaję issue, kiedy chcecie zespołowi umożliwiać podejrzenie modyfikacji w innych plikach. DRAFT oznacza że to issue jest w trakcie pracy, nie musi być tutaj już tip top

• PULL REQUEST - całkowity

  • robicie normalnego PULL REQUESTA kiedy Wasze issue opisane na GitHub jest w pełni skończone i jako takie będzie sprawdzane, tutaj dodawajcie opisy, ułatwi to przeprowadzanie CR i wyłapywanie czy coś jest do poprawki

• PULL REQUEST - PART

  • kiedy zrobiliście do końca część issue (czasem jedno issue może składać się z kilku względnie oddzielnych rzeczy) albo zrobiliście częściowo issue, ale część którą zrobiliście jest komuś potrzebna —> tworzycie PULL REQUEST i w jego nazwie dodajecie PART (tak jak jest to opisane w konwencji opisów)
  • jeśli robicie PART - koniecznie trzeba opisać co zostało zrobione, a czego jesteście świadomi, że zostaje jako TODO na dalszą część tego issue - żeby robiąć CR było wiadomo którą część oceniać, co jest świadomym brakiem i czy ew. pojawiły się nowe rzeczy do zrobienia
  • następnie kończenie issue kontynuujecie na tym samym branchu