Repozytoria organizacji Github, problemy, wielu programistów i rozwidlanie - najlepsze praktyki przepływu pracy

Dziwny tytuł, tak, ale myślę, że mam trochę podstaw.

Mamy konto organizacji na github z prywatnymi repozytoriami. Chcemy korzystać z natywnych funkcji github dotyczących problemów / żądań ściągania (żądania ściągania są w zasadzie dokładnie tym, czego chcemy, jeśli chodzi o recenzje kodu i dyskusje na temat funkcji). Znaleźliśmy centrum narzędzi firmy defunkt, które ma fajną małą cechę polegającą na tym, że jest w stanie przekonwertować istniejący problem na żądanie ściągania i automatycznie powiązać z nim bieżący oddział.

Zastanawiam się, czy najlepszą praktyką jest, aby każdy programista w organizacji rozwiązywał repozytorium organizacji w celu wykonywania ich funkcji / poprawiania błędów itp. Wydaje się, że to całkiem niezły przepływ pracy (ponieważ w zasadzie robi to każdy projekt open source w github), ale chcemy mieć pewność, że możemy śledzić problemy i pobierać żądania z JEDNEGO źródła, repozytorium organizacji.

Mam więc kilka pytań:

1. Czy w tym przypadku właściwe jest podejście typu „rozwidlenie na programistę”? Wygląda na to, że może to być trochę przesada. Nie jestem pewien, czy potrzebujemy rozwidlenia dla każdego programisty, chyba że przedstawimy programistów, którzy nie mają bezpośredniego dostępu wypychanego i potrzebują przeglądu całego kodu. W takim przypadku chcielibyśmy wprowadzić taką politykę tylko dla tych programistów. Więc co jest lepsze? Wszyscy programiści w jednym repozytorium lub widelec dla wszystkich?
2. Czy ktoś ma doświadczenie w korzystaniu z narzędzia hub, a zwłaszcza w funkcji pull-request? Jeśli wykonamy rozwidlenie na programistę (lub nawet dla mniej uprzywilejowanych programistów), czy funkcja żądania ściągania w hubie będzie działać na żądanie ściągania z głównego repozytorium głównego (repozytorium organizacji?) Czy ma inne zachowanie?

EDYCJA
Przeprowadziłem testy z problemami, rozwidleniami i ściągnąłem wnioski i znalazłem to. Jeśli utworzysz problem w repozytorium organizacji, rozwidlaj repozytorium ze swojej organizacji na własne konto github, dokonaj zmian, połącz z główną gałęzią widelca. Podczas próby uruchomienia hub -i <issue #>pojawi się błąd, User is not authorized to modify the issue. Najwyraźniej ten przepływ pracy nie zadziała.

Czy w tym przypadku właściwe jest podejście typu „rozwidlenie na programistę”? Wygląda na to, że może to być trochę przesada. Nie jestem pewien, czy potrzebujemy rozwidlenia dla każdego programisty, chyba że przedstawimy programistów, którzy nie mają bezpośredniego dostępu wypychanego i potrzebują przeglądu całego kodu. W takim przypadku chcielibyśmy wprowadzić taką politykę tylko dla tych programistów. Więc co jest lepsze? Wszyscy programiści w jednym repozytorium lub widelec dla wszystkich?

Chyba zależy od skali twojego zespołu. Pracowałem w małym zespole, w którym mieliśmy tylko jedno repozytorium, a funkcje miały w nim własne oddziały. To działało dobrze dla nas.

Jednak teraz regularnie uczestniczę w większym projekcie open source, w którym kilkadziesiąt osób ma dostęp do centralnego repozytorium. Cały czas pracujemy nad osobistymi repozytoriami i przesyłamy PR dla funkcji, aby kod mógł zostać sprawdzony, chociaż poprawki błędów mogą być wysyłane bezpośrednio. Główne repozytorium zawiera tylko gałęzie master i release, dzięki czemu jest wolne od bałaganu. Gałęzie funkcji znajdują się w repozytoriach osobistych, więc mogą być nadal widoczne dla innych (tworzenie wczesnych PR dla nich ostrzega innych w zespole, że trwają prace nad funkcją). Mogę polecić ten przepływ pracy dla każdego projektu z więcej niż garstką programistów; jedynym minusem jest konieczność pracy z wieloma pilotami.

Podejście „rozwidlenie na programistę” jest bardzo dobrym podejściem, jeśli cenisz recenzje kodu i jego jakość. Zaletą korzystania z żądań ściągania jest to, że przenosi odpowiedzialność z opiekuna na programistę.

Deweloper chce przenieść swój kod do głównej gałęzi i prosi o jego włączenie.

To jest zupełnie inny kontekst niż stary model, w którym ludzie się zobowiązują, a później recenzent musiał im powiedzieć „och, to, co zrobiłeś kilka tygodni temu, nie było tak dobre, napraw to teraz”.

Używamy tego modelu w naszej firmie. Wyciąganie żądań sprawiło, że żądania kodu były wykonalne, zachęcały do ​​dyskusji na temat kodu innych ludzi i generalnie pomogły w jakości kodu, nawet z programistami, którzy byli pierwsi przeciwko nowemu narzędziu. Wydaje mi się, że dzięki temu ludzie traktują recenzje kodu poważniej, ponieważ recenzent musi aktywnie scalić kod z główną gałęzią, zamiast po prostu powiedzieć „ok” lub „nie ok” po tym, jak kod został już zatwierdzony.

Nie zrobiłbym wszystkich rozwidleń i rozgałęzień dla wszystkiego. To dobry model klejnotów open source na githubie, ale twój model należy do organizacji, która normalnie miałaby wyższy poziom zaufania do zmian.

Głównym punktem kontroli źródła jest to, że możesz zobaczyć, wycofać, cofnąć itp. Zmiany. Robienie dużej liczby widelców i gałęzi w twojej sytuacji to przesada IMHO.

Zarezerwowałbym gałęzie na takie rzeczy jak: aktualizacje wersji, zmiana jednego z elementów technologii, praca nad modułem przez 3 miesiące, który ma niewiele wspólnego z główną bazą.

Mogę wcale nie rozwidlać się w organizacji. Ten tryb wydaje się bardziej odpowiedni dla projektów typu open source, które mają inny charakter niż projekty wewnętrzne.

Skoncentrowałbym się na testowaniu i przeglądaniu kodu. Czy ludzie piszą testy? Czy oni są dobrzy? Czy przeglądy kodu są gotowe?