Git злиття без автоматичної фіксації

402

Чи можливо це зробити git merge, але без комісії?

"man git merge" говорить про це:

With --no-commit perform the merge but pretend the merge failed and do not autocommit,
to give the user a chance to inspect and further tweak the merge result before
committing.

Але коли я намагаюся використовувати git mergeз ним, --no-commitвоно все ще автоматично здійснює автоматичний зв'язок. Ось що я зробив:

$> ~/git/testrepo$ git checkout master
Switched to branch 'master'

$> ~/git/testrepo$ git branch
* master
  v1.0

$> ~/git/testrepo$ git merge --no-commit v1.0
Updating c0c9fd2..18fa02c
Fast-forward
 file1 |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

$> ~/git/testrepo$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
nothing to commit (working directory clean)

Далі git logрозкриваються всі коміти з гілки v1.0, об'єднані в головний.

git

— selbie
джерело

616

Зверніть увагу на висновок, роблячи злиття - це говорить Fast Forward

У таких ситуаціях вам потрібно зробити:

git merge v1.0 --no-commit --no-ff

— manojlds
джерело

7

що робити, якщо є конфлікт.

— Юрген Пол

20

@PineappleUndertheSea Швидкі форварди ніколи не викликають конфліктів. У разі "реального" злиття без швидкого --no-commitперемикання вперед перемикач ефективний лише в тому випадку, якщо конфлікт не виникає, якщо конфлікт git ніколи не здійснюватиметься автоматично.

— gronostaj

38

FYI: Якщо ви хочете об'єднати зміни, а потім зробити так, як якщо б ви вручну ввели всі зміни, в які ви об'єдналися (на відміну від традиційного злиття), вам потрібно запустити rm .git/MERGE_HEADзгодом, що змусить git забути, що злиття відбулося.

— Джонн

7

FYI: Ось зразок виводу для успішного злиття:Automatic merge went well; stopped before committing as requested

— kevinarpe

6

Очевидно, я git merge BRANCHENAME --no-commit --no-ffзалишив мою робочу область у стані "MERGING". Не зовсім впевнений, що саме це робить, але простий git stash saveі git stash popцикл, здавалося, повертає все до нормального; зі зміненими файлами з цільової гілки на місці, як задумано, і більше не МЕРГОВИЙ статус.

— MoonLite

49

Ви тут нерозумієте значення злиття.

В --no-commitперешкоджає тому , MERGE COMMIT відбудеться, і це відбувається тільки тоді , коли ви поєднуєте дві розбіжні гілки історії; у вашому прикладі це не так, оскільки Git вказує, що це було "швидке перемотування вперед", і тоді Git застосовує лише послідовно послідовності, які вже є у гілці.

— Самус_
джерело

12

Це не обов'язково очистить плутанину; Я думаю, що це один (відносно рідкісний) час, коли документи дійсно зрозумілі: git help merge=> " --no-commitЗдійснюючи злиття, але роблять вигляд, що злиття не вдалося і не вмикатимуть автокомісію, щоб дати користувачеві можливість перевірити та додатково налаштувати результат злиття перед здійсненням. " Ключ, звичайно, це використовувати його спільно з--no-ff

— michael

6

... можливо, було б менш заплутано відірватися від суворої термінології та описати це так: "git merge", який робить швидкий вперед, не має злиття, оскільки насправді злиття взагалі не існує. Це насправді ідеальна ситуація: швидкі форварди - це хороша річ, а відсутність такої додаткової "злиття" робить сенс. Це хороша поведінка за замовчуванням, і її не можна відключати. (Правильно кажучи, швидкий рух вперед - це тип злиття, але це не "справжнє злиття".)

— michael

4

це стосується політики проекту, в деяких випадках корисно мати / примушувати додаткові "об'єднання комісій", навіть якщо це ff, оскільки вам потрібно позначити включення функції в основну гілку.

— Самусь_

7

...що. Гаразд, я вважаю, що git є майже незмінним. Зокрема, ця відповідь переконала мене спробувати Меркуріал.

— Брайан Гордон

24

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

$ git merge --squash v1.0
$ git commit

— Адріан Лі
джерело

1

Це такий же ефект, якgit merge v1.0 --no-commit --no-ff

— jpierson

2

Ні, різний ефект. Сквош створює новий комітет з новим хешем. Він об'єднує всі комісії у філії в один комітет для злиття.

— Каві Зігель

23

Я вважаю за краще цей спосіб, тому мені не потрібно пам’ятати жодні рідкісні параметри.

git merge branch_name

Тоді він скаже, що ваша філія попереду " #" виконує зобов'язання, тепер ви можете скопіювати ці комісії та ввести їх у робочі зміни за допомогою наступного:

git reset @~#

Наприклад, якщо після об'єднання це 1 набір вперед, використовуйте:

git reset @~1

Примітка. У Windows потрібні котирування. (Як зазначив Джош у коментарях), наприклад:

git reset "@~1"

— Пеллет
джерело

4

На Windows потрібні цитати:git reset "@~1"

— Джош

1

Коли є одна фіксація лише у галузі, я зазвичай це роблю

git merge branch_name --ff

— Сіту
джерело