git merge: застосуйте зміни до коду, який перемістився до іншого файлу

Я зараз намагаюся зробити досить приємний маневр злиття git. Одна з проблем, з якою я стикаюся, полягає в тому, що я вніс деякі зміни в код у своїй гілці, але мій колега перемістив цей код у новий файл у своїй гілці. Тож коли я це зробив git merge my_branch his_branch, git не помітив, що код у новому файлі такий самий, як у старому, і тому жодна з моїх змін там не спостерігається.

Який найпростіший спосіб знову застосувати свої зміни до коду в нових файлах. У мене не буде занадто багато проблем з з’ясуванням, які коміти потрібно повторно застосувати (я можу просто використовувати git log --stat). Наскільки я можу сказати, немає можливості отримати git, щоб повторно застосувати зміни до нових файлів. Найпростіше, що я зараз бачу, - це вручну повторно застосувати зміни, що не виглядає як гарна ідея.

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

У мене була подібна проблема, і я вирішив її, передавши свою роботу, щоб відповідати цільовій організації файлів.

Скажіть, що ви змінили original.txtна своїй гілці ( localгілці), але на головній гілці, original.txtскопійовано в іншу, скажімо copy.txt. Ця копія була зроблена в комітеті, який ми називаємо фіксувати CP.

Ви хочете застосувати всі ваші локальні зміни, комісії Aта Bнижче, які були внесені original.txtдо нового файлу copy.txt.

 ---- X -----CP------ (master)
       \ 
        \--A---B--- (local)

Створіть гілку, що викидається, moveна початковій точці змін git branch move X. Тобто, покладіть moveгілку на фіксацію X, ту, до якої потрібно здійснити об'єднання; швидше за все, це зобов’язання, від якого ви розлучилися, щоб здійснити свої зміни. Як написав користувач @digory doo нижче, ви можете зробити, git merge-base master localщоб знайти X.

 ---- X (move)-----CP----- (master)
       \ 
        \--A---B--- (local)

У цій гілці видайте таку команду перейменування:

git mv original.txt copy.txt

Це перейменує файл. Зауважте, що copy.txtв вашому дереві ще не існувало.
Зробіть свої зміни (ми називаємо це зобов’язання MV).

        /--MV (move)
       /
 ---- X -----CP----- (master)
       \ 
        \--A---B--- (local)

Тепер ви можете відновити роботу поверх move:

git rebase move local

Це має працювати без проблем, і ваші зміни будуть застосовані до copy.txtвашого місцевого відділення.

        /--MV (move)---A'---B'--- (local)
       /
 ---- X -----CP----- (master)

Тепер вам не обов’язково потрібно або потрібно брати на себе зобов’язання MVв історії вашої основної гілки, тому що операція переміщення може призвести до конфлікту з операцією копіювання при фіксації CPв основній гілці.

Вам залишається лише знову відновити роботу, відкинувши операцію переміщення, наступним чином:

git rebase move local --onto CP

... де CPкомітет, де copy.txtбуло введено в іншій галузі. Це відновлює всі зміни, що перебувають copy.txtна вершині комісії CP. Тепер ваша localфілія точно така, як ніби ви завжди змінювались, copy.txtа не original.txtви можете продовжувати об'єднання з іншими.

                /--A''---B''-- (local)
               /
 -----X-------CP----- (master)

Важливо, щоб зміни застосовувались CPабо copy.txtне існували б інакше , а зміни будуть застосовані знову original.txt.

Сподіваюся, це зрозуміло. Ця відповідь приходить пізно, але це може бути корисним комусь іншому.

Ви завжди можете використовувати git diff(або git format-patch) для генерації патча, потім перейдіть вручну, щоб відредагувати назви файлів у патчі та застосувати його за допомогою git apply(або git am).

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

Ось злиття рішення зустрічаючи злиття конфлікту з перейменуванням і редагувати і дозволяти його mergetool визнання правильних 3 джерело злиття файлів.

• Після злиття не вдається через "видалений файл", який ви перейменовано та відредагували:

  1. Ви скасовуєте злиття.
  2. Введіть перейменовані файли у своїй філії.
  3. І знову зливаються.

Покрокові відомості:

Створіть файл.txt:

$ git init
Initialized empty Git repository in /tmp/git-rename-and-modify-test/.git/

$ echo "A file." > file.txt
$ git add file.txt
$ git commit -am "file.txt added."
[master (root-commit) 401b10d] file.txt added.
 1 file changed, 1 insertion(+)
 create mode 100644 file.txt

Створіть відділення, де ви будете редагувати пізніше:

$ git branch branch-with-edits
Branch branch-with-edits set up to track local branch master.

Створіть перейменування та відредагуйте головний:

$ git mv file.txt renamed-and-edited.txt
$ echo "edits on master" >> renamed-and-edited.txt 
$ git commit -am "file.txt + edits -> renamed-and-edited.txt."
[master def790f] file.txt + edits -> renamed-and-edited.txt.
 2 files changed, 2 insertions(+), 1 deletion(-)
 delete mode 100644 file.txt
 create mode 100644 renamed-and-edited.txt

Поміняйте місцями на відділення і там також відредагуйте:

$ git checkout branch-with-edits 
Switched to branch 'branch-with-edits'
Your branch is behind 'master' by 1 commit, and can be fast-forwarded.
  (use "git pull" to update your local branch)
$ 
$ echo "edits on branch" >> file.txt 
$ git commit -am "file.txt edited on branch."
[branch-with-edits 2c4760e] file.txt edited on branch.
 1 file changed, 1 insertion(+)

Спроба об'єднати майстер:

$ git merge master
CONFLICT (modify/delete): file.txt deleted in master and modified in HEAD. Version HEAD of file.txt left in tree.
Automatic merge failed; fix conflicts and then commit the result.

Зауважте, конфлікт важко вирішити - і файли були перейменовані. Скасувати, імітувати перейменування:

$ git merge --abort
$ git mv file.txt renamed-and-edited.txt
$ git commit -am "Preparing for merge; Human noticed renames files were edited."
[branch-with-edits ca506da] Preparing for merge; Human noticed renames files were edited.
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename file.txt => renamed-and-edited.txt (100%)

Спробуйте знову об’єднати:

$ git merge master
Auto-merging renamed-and-edited.txt
CONFLICT (add/add): Merge conflict in renamed-and-edited.txt
Recorded preimage for 'renamed-and-edited.txt'
Automatic merge failed; fix conflicts and then commit the result.

Чудово! Об'єднання призводить до «нормального» конфлікту, який можна вирішити за допомогою mergetool:

$ git mergetool
Merging:
renamed-and-edited.txt

Normal merge conflict for 'renamed-and-edited.txt':
  {local}: created file
  {remote}: created file
$ git commit 
Recorded resolution for 'renamed-and-edited.txt'.
[branch-with-edits 2264483] Merge branch 'master' into branch-with-edits