Częstym scenariuszem w tworzeniu oprogramowania jest przeglądanie kodu cudzego kodu. Typowym narzędziem do tego jest otwieranie żądania ściągnięcia.
Moje pytanie brzmi: kiedy w przeglądzie zostaną znalezione problemy, czy powinny nastąpić zmiany
- być popełnione osobno (nowe zatwierdzenie)
- lub powinien zmodyfikować istniejące zatwierdzenie (zakładając, że nikt nie rozgałęzia się od wcześniejszego zatwierdzenia ... ponieważ ponowne zapisywanie historii z udostępnionego oddziału jest złą wiadomością).
W pierwszym scenariuszu śledzenie zmian przyrostowych jest łatwe, choć dodaje nieco szumu do historii zatwierdzeń. Druga opcja ma odwrotne zalety i wady.
14
Mówisz „szum” do zatwierdzenia, ale czytam, że to dokładna historia . Po co próbować maskować to, co naprawdę wydarzyło się w historii zatwierdzeń? Przegląd kodu to przegląd kodu, nie trzeba go malować jako czegoś innego. Głosowałbym na oddzielne zatwierdzenie, a nie na rebase w tym przypadku.
—
Thomas Stringer
Zwykle robię oba. Opublikuj każde zatwierdzenie osobno, a następnie po zakończeniu przeglądu wyreżyseruj i scal. GitHub prowadzi dyskusje na temat żądania ściągnięcia, nawet po usunięciu lub zastąpieniu tych zatwierdzeń, więc nie ma znaczącej utraty historii w wyniku zmiany wersji. Dostajesz to, co najlepsze z obu światów.
—
Ajedi32
mam mieszane uczucia co do tego, czy popełniłem coś, co jakoś później ustaliłem, powoduje awarię systemu. te zobowiązania, jeśli wkrótce odkryję ich wadę mojego zrobienia, chciałbym wycofać się z historii. ale to tylko drobiazgi, nie kosztują tyle, więc prawdopodobnie najbardziej bezpieczną, opłacalną i konsekwentną rzeczą do zrobienia (jak w doktrynie) jest zawsze zatwierdzanie osobno i pozostawienie wraku samochodu w rowie, aby wszyscy mogli patrz teraz i na zawsze. .... i możesz oznaczyć każdą wadliwą gałąź jednoznacznym komunikatem, aby nie budować na niej, więc nie udostępniaj gałęzi.
—
Robert Bristol-Johnson
Czy możesz wyjaśnić, co to jest „rebasing” i kiedy tego chciałbym?
—
Kilian Foth,