Это может немного расчесывать, но git требует , что все конфликты должны быть разрешены до того, как вы сможете завершить коммит.Однако, с точки зрения git, «разрешенный» означает «пользователь ввел команду git add для пути, содержащего конфликт».Если пользователь говорит «это решено», оставляя маркеры конфликта внутри, git не предполагает, что он знает лучше.
И редакторы, сидящие поверх git, принципиально не отличаются.Они могут представлять конфликт по-другому или управлять рабочим процессом разрешения таким образом, чтобы пользователю приходилось прыгать через обручи, чтобы намеренно оставлять маркеры конфликта в готовом контенте.Но если пользователь буквально говорит, что разрешенный контент -
>>>>>>> their version
some change
-------
different change
<<<<<<< our version
, то ни один инструмент общего назначения не сможет это отменить.
Мой совет: если пользователь фиксирует маркеры конфликта, когда он не должен 'быть (и, конечно, почти всегда так не должно быть), это, вероятно, вопрос обучения.Я бы посоветовал им либо больше узнать о разрешении конфликтов в git, либо использовать некоторые из этих инструментов, которые используют ваши другие разработчики, чтобы вы чувствовали себя лучше, чтобы защитить их от этих ошибок.Я думаю, что пользователь получает максимальную отдачу от мерзавца, если он тратит время, чтобы изучить его достаточно хорошо, чтобы использовать командную строку, но если он этого не делает, то добавляет «безопасность» вокруг одной из многочисленных ошибок, которые могут сползатьв недостаточно информированном использовании инструментов командной строки ... это далеко не исчерпывающее решение.
Если вы все же хотите добавить такую безопасность, лучше всего использовать git hooks.Вы можете добавить хук предварительного получения к репо-источнику, чтобы он отклонял любые push-уведомления, содержащие коммиты, содержащие файлы, содержащие маркеры конфликтов.Вы также можете сделать это доступным для отдельных репозиториев, чтобы использовать их в качестве фильтра предварительной фиксации, чтобы они могли перехватить ошибку раньше, чем ждать, пока не попытаются зафиксировать, чтобы понять, что у них плохая история.
ПростоИмейте в виду, что такой хук делает предположения о допустимом содержании.Эти предположения не являются возмутительными, если сценарий хорошо написан;для многих типов контента действительно не является хорошей причиной для фиксации маркеров конфликта.Но в качестве одного (немного глупого) примера, если у кого-то возникнет необходимость зафиксировать файл .txt, описывающий конфликтующее состояние, сможет ли ваш сценарий определить разницу и пропустить это?
Имеет ли потенциальное преимуществослучаи того стоят, потому что дополнительный уровень безопасности - это то, что вы можете ответить только за ваш проектОпять же, я советую вместо этого решить, почему ваши пользователи делают эти ошибки в первую очередь.