Git szybkie przewijanie VS brak szybkiego łączenia

Scalanie Git pozwala nam wykonywać szybkie przewijanie do przodu i brak szybkiego łączenia gałęzi. Jakieś pomysły, kiedy użyć scalania szybkiego przewijania do przodu, a kiedy nie używać scalania szybkiego przewijania do przodu?

Ta --no-ffopcja jest przydatna, gdy chcesz mieć jasne pojęcie o gałęzi funkcji. Więc nawet jeśli w międzyczasie nie dokonano żadnych zatwierdzeń, FF jest możliwe - nadal chcesz czasami, aby każde zatwierdzenie w linii głównej odpowiadało jednej funkcji. Więc traktujesz gałąź funkcji z zestawem zatwierdzeń jako jedną jednostkę i łączysz je jako jedną jednostkę. Z twojej historii jasno wynika, że ​​dokonujesz scalania gałęzi funkcji --no-ff.

Jeśli nie przejmujesz się takimi rzeczami - prawdopodobnie możesz uciec z FF, gdy tylko jest to możliwe. W ten sposób będziesz mieć bardziej podobne do svn poczucie przepływu pracy.

Na przykład autor tego artykułu uważa, że ​​ta --no-ffopcja powinna być domyślna, a jego rozumowanie jest zbliżone do przedstawionego powyżej:

Rozważmy sytuację, w której szereg drobnych zatwierdzeń w gałęzi „Feature” łącznie tworzy jedną nową funkcję: Jeśli po prostu zrobisz „git merge feature_branch” bez --no-ff, „z ​​historii Gita nie można zobaczyć, które z obiektów zatwierdzania mają razem zaimplementowano funkcję - należy ręcznie odczytać wszystkie komunikaty dziennika. Cofanie całej funkcji (tj. grupy zmian) jest prawdziwym bólem głowy [jeśli --no-ffnie jest używana], podczas gdy można to łatwo zrobić, jeśli --no-ffflaga została użyta [ponieważ to tylko jedno zatwierdzenie]. ”

Mogę podać przykład powszechnie spotykany w projekcie.

Tutaj opcja --no-ff(tj. Prawdziwe scalenie ) tworzy nowe zatwierdzenie z wieloma rodzicami i zapewnia lepsze śledzenie historii. W przeciwnym razie --ff(tj. Scalanie przewijania do przodu ) jest domyślnie.

$ git checkout master
$ git checkout -b newFeature
$ ...
$ git commit -m 'work from day 1'
$ ...
$ git commit -m 'work from day 2'
$ ...
$ git commit -m 'finish the feature'
$ git checkout master
$ git merge --no-ff newFeature -m 'add new feature'
$ git log
// something like below
commit 'add new feature'         // => commit created at merge with proper message
commit 'finish the feature'
commit 'work from day 2'
commit 'work from day 1'
$ gitk                           // => see details with graph

$ git checkout -b anotherFeature        // => create a new branch (*)
$ ...
$ git commit -m 'work from day 3'
$ ...
$ git commit -m 'work from day 4'
$ ...
$ git commit -m 'finish another feature'
$ git checkout master
$ git merge anotherFeature       // --ff is by default, message will be ignored
$ git log
// something like below
commit 'work from day 4'
commit 'work from day 3'
commit 'add new feature'
commit 'finish the feature'
commit ...
$ gitk                           // => see details with graph

(*) Zauważ, że tutaj, jeśli newFeaturegałąź zostanie ponownie użyta, zamiast utworzyć nową gałąź, git i tak będzie musiał wykonać --no-ffscalenie. Oznacza to, że szybkie łączenie do przodu nie zawsze jest możliwe.

Kiedy pracujemy nad środowiskiem programistycznym i łączymy nasz kod z gałęzią pomostową / produkcyjną, wówczas Git nie może być lepszym rozwiązaniem. Zwykle, gdy pracujemy w dziale rozwoju dla jednej funkcji, zwykle mamy wiele zatwierdzeń. Śledzenie zmian za pomocą wielu zatwierdzeń może być później niewygodne. Jeśli połączymy się z gałęzią przemieszczania / produkcji za pomocą Git bez szybkiego przewijania, będzie miał tylko 1 zatwierdzenie. Teraz za każdym razem, gdy chcemy przywrócić tę funkcję, wystarczy przywrócić zatwierdzenie. Życie jest proste.

Możliwe jest również, że ktoś może chcieć mieć spersonalizowane gałęzie funkcji, w których kod jest umieszczany na koniec dnia. Pozwala to na dokładniejsze śledzenie rozwoju.

Nie chciałbym zanieczyszczać rozwoju głównego niedziałającym kodem, dlatego robienie --no-ff może być tym, czego się szuka.

Na marginesie, może nie być konieczne zatwierdzenie działającego kodu w spersonalizowanym oddziale, ponieważ historię można przepisać git rebase -ii wymusić na serwerze, o ile nikt inny nie pracuje w tym samym oddziale.