Git швидко вперед VS немає швидкого злиття вперед

Злиття Git дозволяє нам здійснювати швидке перемотування вперед, а не швидке швидке з’єднання гілок вперед. Будь-які ідеї, коли використовувати швидке злиття вперед і коли не використовувати швидке злиття вперед?

Цей --no-ffваріант корисний, коли ви хочете мати чітке уявлення про вашу галузь функцій. Тож навіть якщо тим часом жодних комісій не було зроблено, FF можливий - ви все одно хочете, щоб іноді кожен комітет у магістралі відповідав одній функції. Таким чином, ви розглядаєте гілку функцій з купою комітетів як єдину одиницю та об'єднуєте їх як єдину одиницю. З історії видно, коли ви виконуєте об'єднання гілок --no-ff.

Якщо вам не байдуже таке - ви, ймовірно, можете піти з FF, коли це можливо. Таким чином, у вас з'явиться більше svn-подібного відчуття робочого процесу.

Наприклад, автор цієї статті вважає, що цей --no-ffваріант повинен бути типовим, і його міркування близькі до того, що я окреслив вище:

Розглянемо ситуацію, коли серія другорядних фільмів на гілці "особливість" колективно складає одну нову функцію: Якщо ви просто робите "git merge feature_branch" без --no-ff", з історії Git неможливо побачити, хто з об'єктів комітету має разом реалізована функція - вам доведеться вручну читати всі повідомлення журналу. Повернення цілої функції (тобто групи комітетів) - це справжній головний біль [якщо --no-ffвона не використовується], тоді як це легко зробити, якщо --no-ffпрапор був використаний [тому що це лише одна фіксація] ".

Я можу навести приклад, часто зустрічається в проекті.

Тут варіант --no-ff(тобто справжнє злиття ) створює нову команду з декількома батьками та забезпечує кращу відстеження історії. В іншому випадку --ff(тобто швидке злиття вперед ) за замовчуванням.

$ 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

(*) Зауважте, що тут, якщо newFeatureгілка буде повторно використана, замість створення нової гілки, git доведеться все-таки зробити --no-ffоб'єднання. Це означає, що швидке злиття вперед не завжди підходить.

Коли ми працюємо над середовищем розробки та об'єднуємо наш код у галузь постановки / виробництва, тоді Git no fast forward може бути кращим варіантом. Зазвичай, коли ми працюємо в галузі розробки для однієї функції, ми, як правило, маємо декілька комітів. Відстеження змін за допомогою декількох комісій згодом може бути незручним. Якщо ми з’єднаємось з постановочною / виробничою галуззю, використовуючи Git no fast forward, то у неї буде лише 1 комісія. Тепер у будь-який час, коли ми хочемо відновити функцію, просто відновіть цю команду. Життя легке.

Можливо також, що ви можете мати персоналізовані гілки функцій, де код просто розміщується в кінці дня. Це дозволяє відстежувати розвиток більш детально.

Я не хотів би забруднювати розробку майстра неробочим кодом, таким чином роблячи - no-ff може бути саме тим, що потрібно шукати.

Як зауваження, можливо, не потрібно вводити робочий код на персоналізовану гілку, оскільки історію можна переписати git rebase -iта примусити на сервері, доки ніхто інший не працює над цією ж гілкою.