В git есть ли способ перезаписать или хотя бы объединить один файл во все открытые ветви?

Question

В любой момент времени у нас есть ветвь мастера и разработки и любое количество открытых исправлений, ветвей функций и т. Д.

Мне интересно, если не считать сценария оболочки, если есть метод дляобъединить один коммит во все ветви?

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

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

Answer 1

Короткий ответ - нет.

Более длинный ответ начинается с того факта, что вы должны как-то определить «открытые ветви», поскольку это не концепция Git.Ветвь name в Git - это просто метка, указывающая на один конкретный коммит.Ветвь часто (в зависимости от того, кто произносит слово) представляет собой неуказанную серию коммитов, которые достижимы из этого конкретного коммита, но иногда это имя ветви.

После того, как вы взялись за это, возможно, дело в малой важности: git for-each-ref ¹ , чтобы получить список всех названий ветвей, отфильтровать его до того, что вы подразумеваете под словом "open", инаписать сценарий оболочки:

... если не считать сценария оболочки ...

Упс.: -)

Сам сценарий оболочки, как правило, довольно прост: он запускает git checkout, чтобы переключиться на нужную ветвь, затем запускает либо git checkout <hash> -- <path> && git commit, либо git merge <hash>, с необходимыми дополнительными аргументами по желанию.Случай слияния должен учитывать, что делать в случае конфликта слияния, и требует, чтобы выбранный <hash> был способен к слиянию для получения желаемого результата, а это действительно сложная часть: соответствующая<hash> может варьироваться от одного имени ветки к следующему, и во всех случаях конкретный коммит должен быть создан до запуска скрипта.

(Вместо git checkout <hash> -- <path>, вы также можете использовать cp /path/to/external/file <path> && git add <path>, конечно.)

---

¹ Не используйте ls .git/refs/heads, так как это не обрабатывает несколько случаев, включая упакованные ссылки и веткичьи имена имеют вид feature/X. Do помните, что git for-each-ref необходимо пространство имен для итерации: базовое - refs/heads, но более интересным может быть refs/remotes/origin.Подробнее см. в документации .