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ń:
- 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?
- 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.