Czy jest sens używania żądań ściągania na moim własnym repozytorium, jeśli jestem jedynym programistą?

Zacząłem więc od mojego prawdziwego projektu na GitHub i wszystko idzie całkiem nieźle, a pomysły płyną znacznie szybciej, niż początkowo myślałem. Aby utrzymać porządek, skonfigurowałem niektóre gałęzie, aby osobno opracować różne funkcje.

Teraz, kiedy przekazuję moją gałąź do GitHub, mam tę sekcję, w której mam dwa przyciski: Pull Requesti Comparez nazwą gałęzi, do której ostatnio naciskałem. Rozumiem cel Compareprzycisku, ale nie rozumiem, dlaczego chciałbym utworzyć żądanie ściągnięcia na moim własnym repozytorium.

Czy ktoś może mi wyjaśnić, dlaczego miałbym to zrobić? Czy użyteczne jest składanie żądania ściągnięcia na własnym repozytorium, jeśli jestem jedynym programistą?

Dla wielu (być może większości) indywidualnych programistów pracujących samodzielnie, tworzenie żądań ściągania prawdopodobnie nie jest opłacalne. Mogę jednak wymyślić co najmniej jeden potencjalny powód:

Żądania ściągania można wykorzystać do łatwiejszego śledzenia historii projektu. Żądanie ściągnięcia ma identyfikator problemu, do którego można się odwoływać z komunikatów zatwierdzenia oraz w dzienniku zmian, co pozwala łatwo wrócić i znaleźć punkt scalenia oraz zestaw scalonych zatwierdzeń dla konkretnej zmiany, bez konieczności zachowania funkcji oddziały w nieskończoność.

Na przykład w Pioneer (wtyczka bezwstydna), kiedy scalamy żądanie ściągnięcia, dodajemy pozycję do dziennika zmian , z jednopoziomowym opisem zmiany i odniesieniem do identyfikatora żądania ściągnięcia. Oczywiście Pioneer ma kilku programistów, ale ten sam mechanizm może być użyteczny dla programisty pracującego samodzielnie.

Może to być mniej przydatne, jeśli zdecydujesz się pozostać przy liniowej historii zatwierdzeń (poprzez zwolnienie gałęzi funkcji przed scaleniem, aby scalenie zawsze można było wykonać jako szybkie przewijanie do przodu) i jeśli jesteś bardzo zdyscyplinowany w edytowaniu i zgniataniu zatwierdza przed połączeniem z master, ponieważ w takim przypadku poszczególne komunikaty zatwierdzenia mogą być same w sobie używane jako dziennik zmian.

Żądania ściągania są tworzone, aby ktoś mógł przejrzeć pracę, dodać komentarze, sugestie, wprowadzić zmiany lub poprosić o edycję, a następnie scalić kod z masterem.

W twoim przypadku kimś jesteś ty.

Jako jedyny programista nadal powinieneś przejrzeć swoją pracę, przefakturować ją i scalić, aby opanować, gdy będzie gotowa.

Jednym z moich podejść jest „zakładanie innego kapelusza”, „wypróbowywanie innych postaci”. Usiądź więc chwilę i postaw się w sytuacji: nowicjusza w grupie; młodszy programista; kolega, którego szanowałeś w przeszłości itp. Spróbuj spojrzeć na to ich oczami i zastanów się, co możesz zrobić, aby zmiana była bardziej oczywista, lepiej napisana z jeszcze lepszymi nazwami, które w jak największym stopniu unikają wiedzy plemiennej i domenowej .

Tak, jak wskazałeś, powinieneś pracować w oddziałach, jeśli chcesz oddzielić funkcje i zmiany, które nie są gotowe do opanowania. Możesz zrobić to wszystko w oddziałach (nie potrzebujesz nawet żądań ściągania, aby nimi zarządzać, jeśli i tak wykonujesz zadania PR, ale może to zapewnić użyteczną strukturę).

Czasem też okaże się, że moja zmiana nie działa, ale zamiast przerażenia próbą wycofania jej z mastera, być może teraz zmieszanego z innymi zmianami master, mogę to wszystko zrobić w gałęzi, którą następnie mogę zignorować / usuń, jeśli coś pójdzie nie tak. To ogromna korzyść.

Powinieneś więc pracować w gałęziach i nie angażować się bezpośrednio w master, dopóki nie zdecydujesz się scalić całego oddziału.

Są to wytyczne - a nie zasady - których należy przestrzegać. Czasami celowo je łamię. Na przykład wczoraj popełniłem poprawkę literówek do opanowania.

Wygląda na to, że masz oddziały zdalne i lokalne. Jeśli nadmiernie odczuwasz narzut związany z tym przepływem pracy, zawsze możesz pracować nad różnymi funkcjami za pomocą lokalnych oddziałów, nie wypychając ich.

Zasadniczo sprowadza się do robienia tego, co działa dla Ciebie. Praca z gałęziami jest ogromną korzyścią dla git, a github sprawia, że ​​jest to naprawdę łatwe, ale jako samotny programista nie ma wielkiej potrzeby korzystania z modelu żądania ściągania i zaangażowanie bezpośrednio w master powinno działać dobrze. Kiedy Twój projekt w końcu odniesie niewiarygodny sukces, a dziesiątki lub setki programistów nad nim pracuje, przekonasz się, że otrzymywanie żądań ściągania od ich widelców to świetny sposób na śledzenie projektu.

Żądania ściągania byłyby zwykle używane albo do recenzji kodu, albo do wkładów od użytkowników z własnym rozwidleniem projektu - dla jednego programisty w projekcie tak naprawdę nie widzę celu.

Powodem, dla którego to robię, jest to, że jest to wygodny sposób, aby upewnić się, że wszystkie zautomatyzowane kontrole przebiegły pomyślnie (kompiluje się, ma prawidłowe formatowanie, testy jednostkowe przechodzą ...).

Niekoniecznie wymagam przejścia wszystkich czeków dla każdego zatwierdzenia, ale chcę, aby szef oddziału głównego zawsze przekazywał czeki. Myślę, że żądania ściągania są łatwym sposobem (być może nie jedynym).

Mówiąc bardziej ogólnie, jest to sposób łączenia haczyków w celu dokończenia zmian. Testy są przykładem; @John wspomniał o tworzeniu informacji o wydaniu jako innym przykładzie.

Żądania ściągania kontra git push ostatecznie sprowadzają się do historii indywidualnej lub wspólnej. Główne repozytorium jest źródłem wszystkich zmian, jeśli inni pobierają i potencjalnie wprowadzają zmiany lokalne, wówczas żądanie wypychania może powodować problemy z tymi użytkownikami, ponieważ są drzewem, które pochodzą ze zmian.

Model żądania ściągania (z niestandardowych oddziałów lub osobistych repozytoriów) służy jako sposób na zapewnienie spójnej historii dla wszystkich osób korzystających z kodu i pochodzących z niego.

Jednym z powodów, dla których umieszczasz kod na github, jest udostępnianie kodu do rozwidlania i ściągania żądań. Nigdy nie wiadomo, kiedy to nastąpi, a utrzymanie spójności historii współtwórców byłoby dużym plusem.