Korzystam z GitHub już od jakiegoś czasu i zwykle przesyłam moje gałęzie funkcji, a następnie uruchamiam pull request, który sam scaliłem. Zauważyłem, że pomogło mi to śledzić, gdzie połączyłem gałęzie.
Ale ostatnio czytałem coraz więcej o tym, jak działa Git i zdałem sobie sprawę, że mogę użyć merge-commits, aby odnieść się do momentu połączenia rozgałęzienia.
Więc co powinienem zrobić podczas scalania gałęzi funkcji w master:
Wykonaj merge-commit na master, a następnie wypchnij go w górę LUB Wypchnij lokalny oddział i uruchom pull request?
Przeczytałem Przedstawiamy żądania ściągnięcia dla 2-osobowego zespołu – połączyć moje własne żądania? i Jaki jest przepływ pracy z 2 osobami nad projektem i Czy powinienem otwierać żądania ściągnięcia z oddziału w oficjalnym repozytorium czy na moim forku? ale żaden z nich nie wydaje się odpowiadać na to, czego szukam.
Komentarze
- Czego dokładnie Twoim zdaniem brakuje w tych odpowiedziach?
- Pierwsza mówi o tym z poczucia, że pull requesty mają być recenzowane. Drugi oferuje przepływ pracy. Trzeci nie jest ' nawet powiązany.
- Patrzę na to na podstawie Sprawdzonych metod lub Jak dbać dobry punkt widzenia historii git .
- Kiedy łączę PR, robię to, scalając gałąź lokalnie. Dzięki temu mogę upewnić się, że scalanie zostanie zastosowane w sposób czysty, i ponownie uruchomić testy przed opublikowaniem wyniku. GitHub ' Żądania ściągnięcia są tylko formalizacją tego przepływu pracy, sam Git nie ma koncepcji PR.
- Kiedy PR zostaje scalony, tworzy scalenie zatwierdzam na serwerze głównym, więc nie ' nie sądzę, że ma to jakiekolwiek znaczenie dla historii gita. Dlatego nie ' nie sądzę, aby był jakikolwiek powód, aby używać jednego lub drugiego poza osobistymi preferencjami między wierszem poleceń a interfejsem użytkownika Github.
Odpowiedź
mechanizm git-merge:
Użycie git merge feature
w trybie głównym powoduje scalenie gałęzi feature
z master
i tworzy merge-commit
(jeśli gałęzi nie można przewinąć do przodu) w historii git. Aby wymusić wykonanie merge-commit
, użyj opcji --no-ff
z merge
.
Mechanizm Merge Pull Request:
Kiedy uruchamiamy pull request na GitHub, tworzy on GitHub Issue
gdzie ludzie mogą rozmawiać i omawiać zmiany w PR przed ich scaleniem. Kiedy PR jest scalany w GitHub, robi dokładnie to samo, co git merge feature
.
Co powinienem zrobić ?
Więc jeśli chodzi o historię, nie ma między nimi różnicy.
A jeśli chodzi o wkład, twoi współpracownicy nie będą mieli zrobić coś innego w obu sytuacjach. Są takie same (bez miłego, małego czatu).
Najlepsze praktyki:
Nie mogłem znaleźć najlepszych praktyk, ale logika mówi, że PR nie są zbyt pomocne, jeśli w repozytorium jest tylko jeden współtwórca.
@lxrec i @amon pomogły mi dojść do tego wniosku.
Komentarze
- Wskazówka:
git merge
może nie zarejestrować zatwierdzenia scalającego, jeśli umożliwia „szybkie przewijanie do przodu”. Aby wymusić zatwierdzenie scalania, możesz dodać opcję--no-ff
. - Wolę robić to git-merge na lokalnym, niż na githuib.com, jeśli miałbym coś takiego na github.com Wolałbym nie robić bezpośrednio w gałęzi master, wolałbym raczej wziąć gałąź inną niż master, którą można najpierw ustawić w trybie przejściowym przed udostępnieniem jej do produkcji.
Odpowiedź
Jak powiedział Ashhar , pod względem technicznym i historycznym nie ma różnicy. W przypadku projektów z mały zespół Wolę scalać bezpośrednio zamiast dodatkowego etapu tworzenia PR. Jednak gdy funkcja wymaga przeglądu / opinii lub jest to WIP i więcej niż jedna osoba będzie nad nią pracować, zwykle otwieram PR i dodam lista zadań do opisu PR.
Zwróć uwagę, że git merge
może używać szybkiego przewijania do przodu, jeśli nie ma zmian do nadrzędnego, więc możesz chcieć użyć git merge --no-ff
. Zwykle tego nie robię.
Podsumowując, używaj tylko PR kiedy potrzebujesz dyskusji. W przeciwnym razie po prostu scal bezpośrednio.
Komentarze
- To ' warto również wspomnieć, że dyskusja i opinie na temat żądania ściągnięcia mogą pochodzą ze źródeł automatycznych, a także członków zespołu. Jeśli masz skonfigurowany serwer CI, może on dać wyniki kompilacji i testów, więc nigdy nie scalisz czegoś, co zepsuje kompilację na wzorcu.