Najlepsze praktyki dla repozytoriów git w projektach open source

Question

Wnoszę wkład w dość mały projekt open source na Github. Aby inni mogli skorzystać z mojej pracy, stworzyłem własne widły na Githubie. Pomimo wyboru terminologii Githuba, nie chcę całkowicie odbiegać od głównego projektu. Jednak nie oczekuję ani nie pragnę, aby cała moja praca została zaakceptowana w głównym repozytorium. Jednak część z nich została już scalona z głównym repozytorium i oczekuję, że będzie kontynuowana. Problem, który napotykam, polega na tym, jak najlepiej utrzymywać nasze dwa drzewa w stanie, w którym kod może być łatwo dzielony między nimi.

niektórych sytuacjach mam albo spotykane to:

• zobowiązuję kod, który jest później zaakceptowane do głównego repozytorium. Kiedy w przyszłości ściągnę z tego repozytorium , moje zatwierdzenie zostanie zduplikowane w moim repozytorium .
• Zatwierdzam kod, który nigdy nie jest akceptowany w głównym repozytorium. Kiedy wycofam się z tego repozytorium w przyszłości, oba drzewa rozdzieliły się i naprawienie było trudne.
• Inna osoba przychodzi i opiera swoją pracę na moim repozytorium. W związku z tym powinienem, o ile to możliwe, unikać zmian, które popchnąłem, na przykład przez użycie git rebase.
• Chcę przesłać kod do głównego repozytorium. Najlepiej byłoby, gdyby moje zmiany były łatwe do przekształcenia w łatki (najlepiej za pomocą łatki git format-patch), które mogą bezpośrednio i czysto zastosować do głównego repozytorium.

O ile mogę powiedzieć, że są dwa, a może trzy sposoby, aby sobie z tym poradzić, z których żaden nie działają szczególnie dobrze:

• Najczęściej uruchomić git rebase zachować moje zmiany opiera się na czele repozytorium upstream. W ten sposób mogę wyeliminować zduplikowane zatwierdzenia, ale często muszę przepisać historię, powodując problemy dla osób, które chcą czerpać swoją pracę z moich.
• Często scalaj zmiany w repozytorium w moje. Działa to dobrze na moim końcu, ale nie ułatwia przesyłania mojego kodu do repozytorium.
• Użyj pewnej kombinacji tych i ewentualnie git-pick, aby utrzymać porządek.

Co zrobili inni ludzie w tej sytuacji? Wiem, że moja sytuacja jest analogiczna do relacji między różnymi uczestnikami jądra i głównym repozytorium Linusa, więc mam nadzieję, że istnieją dobre sposoby, aby sobie z tym poradzić. Jestem całkiem nowy, ale nie opanowałem wszystkich jego niuansów. Wreszcie, szczególnie z powodu Github, moja terminologia może nie być całkowicie spójna lub poprawna. Możesz mnie poprawić.

Answer 1

Kilka wskazówek nauczyłem z podobnej sytuacji:

• Czy zdalny oddział śledzenia pracy przez głównego autora.
• Co jakiś czas przesuwaj zmiany z tej gałęzi śledzenia do swojej głównej gałęzi.
• Utwórz nowy oddział dla każdego z tematów, nad którymi pracujesz. Te gałęzie powinny być generalnie tylko lokalne. Po wprowadzeniu zmian z poziomu nadrzędnego do wzorca, zmień gałęzie tematów, aby odzwierciedlić te zmiany.
• Po zakończeniu pracy z tematem połącz się z mistrzem.W ten sposób, ludzie, którzy czerpią pracę z twojej, nie zobaczą zbyt wiele przepisanej historii, ponieważ rebase pojawił się w twoich lokalnych gałęziach tematycznych.
• Przesyłanie zmian: Twój główny oddział będzie w zasadzie serią zatwierdzeń, z których niektóre są takie same jak poprzednie, a pozostałe należą do ciebie. Ten drugi może zostać wysłany jako łatka, jeśli chcesz.

Oczywiście, wybór nazw firmowych i pilotów jest twój. Nie jestem pewien, czy są one wyczerpujące dla scenariusza, ale obejmują większość moich przeszkód.