Mój 10-osobowy zespół używa GitHub do naszego projektu rozwojowego. Mamy głównydevelop oddział, z którego tworzymy gałęzie funkcji do wykonywania naszych zadań rozwojowych, a następnie scalamy gałęzie funkcji z powrotem dodevelop. Korzystamy z Pull Requestów, aby dokonywać recenzji kodu. Wszystkie standardowe rzeczy.

Jednak jedna rzecz mnie niepokoi.

Powiedz, że programista A utworzy gałąź o nazwiemyFeature. Na przykład w tej gałęzi dokonuje zmiany jednej linii do pojedynczego plikuLoop.java.

W międzyczasie połączonych jest 100 niepowiązanych zatwierdzeńdevelop z innych oddziałów, przez innych programistów.

Teraz, zanim deweloper A przesunie swoje zmiany i wyśle ​​żądanie ściągnięcia, chce się upewnić, że jego zmiany będą działać z najnowszymidevelop Oddział. W ten sposób łączy HEADdevelop do jego oddziału:

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

Ostatnie polecenie (git merge develop) zawsze powoduje nowe zatwierdzenie. Tak więc, gdy deweloper A przesuwa swoje zmiany i wydaje żądanie ściągnięciamyFeature, recenzent żądania ściągnięcia zobaczy 101 zatwierdzeń dodanych do oddziałumyFeature: jedna ma zmianę naLoop.java, a pozostałe 100 są niepowiązane i już w rzeczywistości zostały połączonedevelop. Tutaj służą jedynie jako szum, aby ukryć to, co zostało naprawdę zmienione przez dewelopera w tej branży.

Czy recenzent może w łatwy sposób powiedzieć, co zostało zmienione po zmianie A przez programistę i jakoś „ukryć” zatwierdzenia, które pochodzą z połączenia zdevelop? Myślę szczególnie o karcie „Zmieniono pliki” w widoku Żądanie ściągnięcia. (Zdaję sobie sprawę, że mogłem użyć zakładki „Commits” i przejść przez wszystkie zatwierdzenia jeden po drugim, aby zobaczyć, co się zmieniło, ale może to być męczące, jeśli istnieje wiele zatwierdzeń. Podoba mi się pojedynczy, ostateczny widok „ Pliki zmienione „karta”.

EDYTOWAĆ: git rebase develop został zaproponowany jako opcja, ale nie sądzę, że jest to odpowiednie dla naszych celów. Często pracuje nad wieloma programistamimyFeature, więc rebase ma potencjał, by zepsuć wszystkich, ponieważ przepisuje historię.

EDYCJA 2: Jak uprzejmie zauważyłem poniżej, GitHub zachowuje się dobrze: tak, pokaże zatwierdzenie scalania w zakładce „Commits” żądania ściągnięcia (co jest w porządku), ale tylko w zakładce „Files Changed” wymienione zostaną pliki zmienione w tej gałęzi funkcji (a nie te z scalenia). To jest dokładnie to, czego szukam.