GitAttribute для принудительного ручного слияния, специфицирующий c файл

Question

Мой репозиторий имеет версию. json, где мы храним основную и вспомогательную версию базы кода.

Как настроить git, чтобы не автоматически объединить изменения в этот файл?

Например, версия . json содержит { "version": "1.2"}, и у меня есть две ветви функций, которые увеличивают его до "1,3", я хотите, чтобы последнее слияние вступило в конфликт:

A--B-----PR1--PR2
   | \  /     /
   |  F1     /
   F2--------

Оба F1 и F2 вносят одно и то же изменение в версию . json, они оба редактируют его как { "version: "1.3" }. Коммит слияния PR1 подойдет, но я бы хотел, чтобы слияние PR2 потребовало ручного просмотра файла version. json (потому что нам нужно установить версию 1.4 ).

Я попытался создать .gitattribute для обработки файла version. json как двоичного, но git, похоже, все еще мог объединить результаты.

Answer 1

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

Когда Git выполняет объединение двух разных коммитов, он сравнивает каждый файл в дерево в обеих головках, которое оно объединяет (в данном случае PR1 и F2) с учетом переименований. Если файлы идентичны в обоих случаях (то есть, у BLOB-объектов одинаковые значения ha sh), он объединит их, просто взяв в качестве результата версию, которая есть в обеих заголовках, без учета чего-либо еще.

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

Если у вас есть два файла, которые отличаются, вы можете использовать version.json -merge, чтобы заставить их конфликтовать в любое время, когда они изменились, но это не повлияет на идентичные файлы.

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