Попытка найти «топать» слияния в GIT - PullRequest
Новая
       110

Попытка найти «топать» слияния в GIT

0 голосов
/ 11 апреля 2019

Абстрактный Сценарий: есть мастер и ветка.ветвь потомок это хозяин.Наряду с другими файлами, не показанными здесь, оба содержат подкаталог с именем subdir, который содержит выбор json-файлов: 

branch:
/subdir/1.json
/subdir/2.json

master:
/subdir/2.json
/subdir/3.json

Что я хотел бы сделать, это объединить только подкаталог с master на ветку, где всефайлы в subdir ветви удаляются и заменяются содержимым master, не теряя историю коммитов в ветке и не затрагивая другие файлы в ветке.

Так что после слияния subdir ветки и subdir master выглядят в точности както же самое.

1 Ответ

2 голосов
/ 11 апреля 2019

Нет аргумента слияния, который заставляет это делать.

- это способ сделать это в рамках одного слияния, но эта может быть плохой идеей. Этот тип слияния называется злым слиянием , по крайней мере, некоторыми (см. Злые слияния в git? для различных взглядов на то, что именно является "злым слиянием"). Способ сделать это «не злым» - это выполнить слияние, зафиксировать результат, а затем сделать последующий коммит, который исправит ситуацию. Другой способ сделать это "не зло" - сделать коммит, который делает слияние правильным, а затем выполнить слияние. В любом случае у вас есть два коммита, одним из которых является обычное ежедневное слияние без зла.

Но если вы хотите сделать это как одно слияние, devil-may-care относительно того, является ли это злом или нет, вот как вы это делаете: 

$ git checkout branch
$ git merge --no-commit -s ours master
... Git does the merge, but stops before committing ...

$ git rm -r -- subdir           # needed only if there are files to remove

$ git checkout master -- subdir
$ git status                    # use git status often!
... you'll see some status ...
$ git diff --cached HEAD        # optional: see what's changing vs tip of branch "branch"
... you'll see some status ...
$ git diff --cached --name-status HEAD  # optional: see what files differ
... you'll see some status ...
$ git status                    # it's never wrong to use git status too often
... you'll see some status ...
... ok, we're really ready ...
$ git commit
<and write a good merge message>

Обратите внимание, что после этого слияния Git теперь считает, что правильный результат объединения двух коммитов, которые вы только что скомбинировали, это то, что вы только что совершили. Это влияет на будущие операции слияния!

Обратите внимание на шаг git rm -r (сначала я об этом забыл): вам это нужно, если в текущем (tip-of- branch) файле есть файлы, которые не в master tip commit, который должен быть удален при слиянии. Если таких файлов нет, git rm -r не является вредным, но не делает ничего полезного: мы просто заменим все файлы следующим шагом git checkout master -- subdir.

...