Z tego co wiem Git ma kontrolę dostępu, tzn wybierasz kto może robić commity. W ten sposób w swoim repo nie masz nic czego nie "klepniesz". Oprócz tego publika może wrzucać pull requesty swoich forków, ale nie mieszają się z resztą bazy kodu. Przyjmowanie czy odrzucanie jest dość prostym procesem. Ktoś może opiekować się repo w kwestii porządkowej, może jakaś grupa alpha i betatesterów.
Dalej podzieliłbym repo na 3 gałęzie, stable - aktualna działająca i przetestowana wersja MaSzyny, beta - działająca, ale nie przetestowana do końca, i alpha - najnowsza w trakcie rozwoju, nie musi działać.
Utrzymanie porządku zapewnia w dużej mierze samo narzędzie. Od reszty są ludzie. Co do poprawności poprawek - wystarczy opracować jakieś kryteria testów. Nie wierzę, że nie znajdą się chętni do testowania czy opieki nad repo. Tak samo jak nie wierzę, że wśród chętnych nie znajdą się kompetentni. Trochę wiary w ludzi. To procentuje.
Mówisz, że repo jest zabugowane. No to od tego jest O/S, żeby bugi usuwać. Jeśli się to ludziom utrudnia zamiast ułatwiać, to cóż, idzie wolniej, nie szybciej.
Poza tym serio myślisz, że ktoś będzie zmieniał coś w plikach o których nie ma bladego pojęcia dla zabawy? To czysty absurd. Projekty Open Source nie mogłyby w ogóle powstawać ani działać, gdyby ludzie robili tak głupie, a jednak wymagające trochę ukierunkowanego wysiłku rzeczy. W projektach, które prowadziłem coś takiego się jeszcze nie zdarzyło ani razu. Nie robisz commita jak nie wiesz co robisz. Idiota nie wie nawet co to jest commit ;) Zdarzały mi się commity, które klepnąłem, a miały bugi. Jeden telefon do gościa, który to commitował - i raz, że było poprawione, dwa, wszystkie kolejne jego commity były bez zarzutu. Na marginesie gość, który zaczynał w firmie jako świeżak przejmie moją robotę po mnie w całości. Nie dało by się tak zrobić, gdybym miał podejście "ja siam! ty się nie znasz, zostaw bo zepsujesz". Dałem mu trochę popsuć, i przejął większość roboty.
Prawdziwe filtrowanie (z testowaniem) powinno odbywać się głównie przy przenoszeniu rzeczy pomiędzy gałęziami. Na początku pomiędzy czyimś forkiem, a projektem alpha, potem pomiędzy alpha i beta, potem pomiędzy beta i stable.
Oczywiście ja nie mówię weźcie i zróbcie, ja mówię zróbmy, chętnie pomogę. Mogę testować. Mogę porządkować. Mogę sprawdzać niektóre rzeczy (czy z grubsza wydają się poprawne). Mogę napisać narzędzia np do poprawiania struktury plików z automatu.
Tak na koniec, boisz się, że Ci walnę buga w czymś, nad czym się napracowałeś? Jasne, że tak. Nie myli się tylko ten, co nic nie robi. Przy poprawianiu błędów i ulepszaniu dochodzą nowe. To naturalny proces, a nie powód, żeby zamykać projekt. Za parę miesięcy nie tylko nie będę robił większości błędów, ale poprawiał błędy innych i uczył. Mam wrócić za parę miesięcy? Nie.
