Как объединить изменения, добавленные после определенной ревизии (в обоих направлениях)?

Can git merge в основном игнорирует некоторые удаления файлов и переименовывает файлы между двумя ветвями, сливая только последующие изменения в файлы, которые были переименованы (и игнорируются изменения в файлах, которые были удалены в одной ветке), туда и обратно между две ветки?

Таким образом, я хотел бы иметь возможность объединить изменения между двумя ветвями. Разветвление development первоначально является копией ветки master, но с многочисленными удалениями и переименованиями файлов.

Эта последняя точка - это то, что нарушает метод, который я пробовал:

Я надеялся, что это каким-то образом определит некоторую отправную точку, так что любой последующий git merge из любой из ветвей применит только изменения, сделанные после того, как они сливаются выше. Вместо этого слияние приводит к тому, что ветки становятся идентичными (насколько я могу видеть), тогда как мне нужно поддерживать ветвь development худой и чистой (меньше файлов, лучше расположение файлов) и завершение ветки master завершено (все файлы в местах, подходящих для развертывания), а также возможность импорта всех изменений (после первоначальных удалений и переименований) в обоих направлениях. Можно ли это сделать с помощью git?

Ответы

Ответ 1

После тщательного рассмотрения документации на https://www.kernel.org/pub/software/scm/git/docs/git-merge.html:

Основная идея слияния - это, в определенном смысле, попытка сделать текущую ветвь идентичной другой ветке или конкретному фиксации в другой ветке путем включения изменений, которые произошли since they diverged из одного из них в другое, это именно то поведение, которое вы получаете. Ключевое слово "расходится". Вы можете указать, какая фиксация объединяется "до", а не коммит, поскольку, когда вы хотите объединиться, объединение всегда возвращается в историю вплоть до момента, когда оба потока идентичны или начинаются с них, а затем повторяет изменения, которые произошли в источнике слияния снова на цель слияния. Эта часть поведения (где она сначала пытается найти общего предка для обеих точек и воспроизводить изменения с этой точки) не может быть изменена никаким параметром в команде слияния, никакая стратегия слияния не может ее изменить. ours указывает, что он игнорирует изменения из других ветвей и всегда заканчивает тем, что в качестве конечного результата имеет текущее дерево ветвей. recursive -Xours заставляет его сливаться и поддерживать текущую версию ветки в конфликтах, но оба сначала возвращаются к общей точке или к началу истории для источника слияния.

Я понял это: у вас есть проект с большим деревом и большим количеством файлов. При разработке функций, которые вы хотите сосредоточить на этих файлах, вы будете модифицировать, чтобы удалить некоторые файлы, изменить их, чтобы их было легче обрабатывать, работать с ними, а затем хотеть интегрировать изменения в главную ветвь. Это просто не то, что слияние должно делать очевидно. Нет опции для команды, которая просто сообщает ей, чтобы начать слияние с определенной точки вперед

Однако вы можете с небольшим изменением стратегии достичь желаемого эффекта с комбинацией git format-patch и git apply/git am Во-первых, когда ветки идентичны, в development удалите все ненужные файлы, но сохраните структуру. Начните работу с файлами, которые вы хотите.

Когда изменения будут готовы перейти на мастер, скажем, вы сделали 5 коммитов к тому времени. Выполните что-то вроде:

git format patch -5 --stdout > /some_folder/patchname.patch

Теперь вы можете проверить мастер и применить патч, который вы создали в /some _folder/patchname.patch, используя что-то вроде

git am --signoff < /some_folder/patchname.patch

сначала вы можете проверить, все ли в порядке:

git apply --check /some_folder/patchname.patch

Другой способ - использовать git cherry-pick (см. https://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html), чтобы вручную выбрать то, что вы обязуетесь передать между двумя ветвями.

Надеюсь, что это поможет.