Jaka jest właściwa etykieta i zalecany przepływ pracy GitHub do jednoczesnego przyczyniania się do repozytorium i odchodzenia od niego?

Jestem nowy w GitHub i ogólnie VCS. Od lat programuję w różnych językach, ale zawsze pracowałem solo nad niestandardowymi projektami (brak publikacji publicznych). Niedawno zacząłem używać widżetu interfejsu użytkownika jQuery, który pobrałem z GitHub w projekcie, nad którym pracuję. Repo nie jest już utrzymywane przez pierwotnego autora. Kolejny widelec zawiera niektóre z pierwotnych żądań ściągnięcia. To z tego rozwidliłem.

Znalazłem kilka błędów i wymyśliłem dla nich poprawki. Chciałbym wprowadzić te poprawki, ale mam też wiele innych zmian, które chcę wprowadzić na własny użytek, które zepsują niektóre z istniejących funkcji. Dodatkowo chciałbym wprowadzić pomysł z innego widelca.

Wciąż uczę się GIT i GitHub i staram się znaleźć najlepszy sposób na wszystko. Dużo przeczytałem (tutaj, SO, strony pomocy GitHub, Pro Git) o ​​różnych koncepcjach / zadaniach: przepływach pracy, scalaniu, żądaniach ściągania, wybieranie wiśni, rebasing, rozgałęzianie. Moja szara materia płynie i muszę zacząć robić, aby lepiej zrozumieć to, co przeczytałem.

Główne kwestie:

1. Wydaje mi się, że przeczytałem (gdzieś), że możesz mieć tylko jedno żądanie ściągania na gałęzi na raz. Czy to oznacza, że ​​powinienem mieć osobną gałąź dla każdego błędu, a następnie osobne żądanie ściągania dla każdego?

2. Chcę usunąć problemy z białymi znakami i wydaje mi się, że pamiętam, że najlepiej to zrobić w osobnym zatwierdzeniu. Czy powinienem to zrobić w swoim master lub w oddzielnym oddziale? Nie chcę wysyłać żądania ściągnięcia dla czegoś tak trywialnego , ale jeśli wprowadzę zmiany białych znaków przed rozgałęzieniem, czy wpłynie to na żądanie ściągnięcia dla poprawek błędów? Niektóre widelce wyczyściły spacje i skutecznie sprawiły, że diff był całkiem bezużyteczny.

3. Myślałem o stworzeniu problemów przeciwko mojemu widelcowi jako sposobie dokumentowania błędów, mimo że już je naprawiłem. Czy to dobry pomysł? Jak przejść do łączenia ze sobą problemu, zatwierdzenia i scalania do opanowania? Jeśli złożę żądanie ściągnięcia w górę, czy mój problem pojawi się również w górę, czy też link do dokumentacji zostanie utracony? Nie mogę otworzyć problemu z repozytorium nadrzędnym (nie ma zakładki problemu).

4. Jaki jest najlepszy sposób, aby podziękować innemu autorowi widelca za pomysł, którego chcę użyć? Nie mogę dokładnie użyć jego kodu, zwłaszcza, że ​​jego zmiana została zastosowana w stosunku do starszej wersji upstream i nie jest kompatybilna z moimi innymi zmianami. Ale chcę skorzystać z tego pomysłu i chcę przyznać kredyt tam, gdzie jest to należne. Czy powinienem po prostu link do jego repozytorium (lub profilu lub konkretnego zatwierdzenia) w mojej wiadomości zatwierdzenia?

5. Jaka jest etykieta dotycząca zmiany pliku readme i DocBlock u góry głównego pliku? Czy mogę wprowadzać zmiany, dodawać moje imię, dodawać linki do mojego repozytorium i wersji demo, usuwać linki do oryginalnej wersji demo (ponieważ mój widelec skończy się niezgodny z oryginałem)? Oczywiście pozostawię oryginalną nazwę autora i informacje o licencji. Dla przypomnienia, jest licencjonowany na licencji MIT.

Jako solowy programista, który nigdy nie korzystał z VCS, jestem przyzwyczajony do przepisywania historii . Jestem perfekcjonistą i lubię porządek i porządek. Idea zapisanej historii trochę mnie denerwuje i chcę to zrobić dobrze za pierwszym razem . Utworzyłem nowe repozytorium do gry / nauki, ale zależy mi na poprawieniu widgetu interfejsu użytkownika jQuery, aby móc kontynuować projekt.

1. Prawidłowo: żądanie ściągnięcia jest powiązane z oddziałem w twoim repozytorium. Jeśli zmodyfikujesz gałąź, modyfikujesz również to, co przesyłasz jako żądanie ściągnięcia.

   Więc tak, musisz utworzyć gałąź (i żądanie ściągnięcia) dla każdej poprawki błędu. Rozsądnie byłoby zacząć od jednego i zobaczyć, jak opiekun zareaguje na ten, zanim przejdzie do reszty. Open source jest z natury procesem społecznym.

2. Do dokonania pull-prośbę, aby zmiany białych! Mówiąc jak ktoś, kto czasami jest opiekunem, uwielbiam tego rodzaju prośby ściągania: albo je zatwierdzam, albo nie, a ich przetworzenie zajmuje niewiele czasu.

   Możesz również spotkać się z tym, że opiekun nie zgadza się z twoimi zmianami białych znaków! Uważajcie więc ...

3. Hmm .. Nie jest jasne, co próbujesz tutaj osiągnąć. To brzmi jak nadmierna dokumentacja i niezbyt dobry pomysł - może możesz wyjaśnić, dlaczego chcesz to zrobić?

4. Odsyłacz do jego repozytorium w wiadomości zatwierdzającej (lub nawet w komentarzu w kodzie) to świetny sposób na uznanie. Bądź jednak ostrożny - wyraźnie zaznacz, że dziękujesz mu za jego pomysły, a nie za jego kod. Jeśli skopiowałeś kod, wysłałbym mu e-mail na ten temat, chyba że jest bardzo jasne, jakiej licencji używa do swojego kodu. Jeśli licencja jest jasna (i jest to inna licencja niż repozytorium, do którego przesyłasz zatwierdzenie), musisz dodać inną licencję do żądania ściągnięcia, a także wspomnieć o tym w komunikacie żądania ściągnięcia.

5. To jest naprawdę dobre pytanie i różni się w zależności od tego, z kim rozmawiasz. Uważam, że nigdy nie powinieneś dodawać swojego nazwiska do żadnego zatwierdzenia lub kodu, który robisz. Głównym powodem jest to, że implikuje „własność i odpowiedzialność za kod” - może uniemożliwić innym modyfikowanie kodu, ponieważ „jest twój”. Ale teraz zaczynamy wielką dyskusję na temat natury open source, więc zatrzymam się tutaj i powiem - zapytaj opiekuna projektu lub po prostu zrób to i zobacz, jaka jest jego reakcja.

6. Możesz przepisać (swoją lokalną, jeszcze nie opublikowaną) historię za pomocą GIT! Naucz się polecenia git rebase - to jeden z głównych powodów, dla których kocham git. To naprawdę zły pomysł, aby (wymusić) wypisanie przepisanych commits / history do wspólnego repozytorium (na przykład github). Spowoduje to następnie uszkodzenie repozytoriów, które mają inni programiści - będą musieli robić trudne rzeczy podczas wyciągania zmian (zapisanej historii).

[# 6: Dzięki @toxalot!]