Czy istnieje sposób, aby "ukryć" scalać zatwierdzenia w GitHub, porównując gałęzie?

Question

Mój zespół złożony z około 10 osób korzysta z GitHub do naszego projektu rozwoju. Mamy główną gałąź develop, z której tworzymy gałęzie funkcji do wykonywania zadań rozwojowych, a następnie scalamy gałęzie funkcji z powrotem do develop. Używamy wniosków Pull Request do przeglądania kodu. Wszystkie standardowe rzeczy.

Jednak jedna rzecz mnie zawracała.

Załóżmy, że programista A tworzy gałąź funkcji o nazwie myFeature. W tej gałęzi wykonuje on jedną linię zmiany do pojedynczego pliku, na przykład Loop.java.

W międzyczasie 100 niepowiązanych zatwierdzeń zostaje połączonych z innymi oddziałami przez innych deweloperów do develop.

Teraz, zanim programista A przesyła swoje zmiany i wysyła żądanie pobrania, chce się upewnić, że jego zmiany działają z najnowszym numerem develop. W ten sposób, że łączy szef develop do swojego oddziału:

git checkout develop 
git pull 
git checkout myFeature 
git merge develop 
# testing and stuff 
git push origin myFeature 

Ostatnia komenda (git merge develop) zawsze skutkuje nowy popełnić. Tak więc, gdy programista A przesyła swoje zmiany i wydaje żądanie pobrania dla myFeature, recenzent żądania wyciągnięcia zobaczy 101 zgłoszeń dodanych do oddziału myFeature: jedna z nich ma zmianę na Loop.java, a pozostałe 100 nie są powiązane i już zostały połączone w develop. Tutaj służą one jedynie jako szum, aby ukryć to, co naprawdę zmieniło się w tej gałęzi od programistyA.

Czy istnieje łatwy sposób, aby recenzent mógł powiedzieć, co zmieniło się po zmianach wprowadzonych przez dewelopera A i "ukryć" zatwierdzenia pochodzące z scalenia z develop? Mam na myśli kartę "Files Changed" w widoku Pull Request. (Zdaję sobie sprawę, że mogłem użyć zakładki "Zatwierdzenia" i przejść przez wszystkie zatwierdzenia jeden po drugim, aby zobaczyć, co się zmieniło, ale może to być męczące, jeśli jest dużo zatwierdzeń. Podoba mi się pojedynczy, ostateczny widok Zakładka "Files Changed".)

EDIT: git rebase develop został zaproponowany jako opcja, ale nie sądzę, że jest to właściwe dla naszych celów. Często wielu deweloperów pracuje nad myFeature, więc rebase może narobić zamieszania, ponieważ przepisuje historię.

EDIT 2: Jak @kan uprzejmie wskazał poniżej, GitHub jest rzeczywiście zachowuje się ładnie: tak, to pokaże scalanie popełnić w „zobowiązuje” zakładkę Pull Request (co jest całkowicie w porządku), ale pod na karcie "Zmienione pliki" wymieniono tylko pliki zmienione w tej gałęzi funkcji (a nie te z scalania). Właśnie tego szukam.

Answer 1

Jedną z metod byłoby raczej niż wykonanie git merge do git rebase develop. Nie spowoduje to zatwierdzenia scalenia i umieszczenia nowego zatwierdzenia na końcu nowych zmian w rozwinięciu.

Historie powinny pokazywać tylko jedno nowe zatwierdzenie zmienione w żądaniu pobierania. IMO to również utrzymuje historię dość liniową i łatwiejszą do naśladowania.

Answer 2

Tak, można to zrobić z bazą danych.

git checkout myFeature 
git fetch 
git rebase origin/develop 
git checkout develop 
git merge @{upstream} 
git merge myFeature # it will do fast-forward, so no merge commit 

Należy jednak mieć świadomość, że rebase powinny być stosowane tylko wtedy, gdy myFeature nie jest dzielona między innymi deweloperami.

BTW, używamy gerrit. To pozwala na rebase a changeset przed scaleniem. Oczywiście, jeśli działa tylko wtedy, gdy nie ma konfliktów, jeśli tak, powinieneś zrobić to ponownie lokalnie i ponownie przesłać zestaw zmian.