Как вы обеспечиваете поведение git, в том числе локально (особенно в Windows)?

Я собираюсь перевести этот .NET-магазин из svn в git и выявил некоторые вспомогательные проблемы, решение которых я хотел бы найти, прежде чем переключить переключатель.

В частности, в этом вопросе я спрашиваю о принудительном исполнении. По умолчанию git для windows устанавливается с 'checkout crlf, commit lf', который не будет работать для группы источников, которая (насколько я знаю) состоит исключительно из окончаний crlf.

Я не знаю, слепо ли я доверял бы любому данному разработчику для правильной настройки даже данной инструкции, поэтому я рассматриваю одно (или оба) из следующего, но мне было бы любопытно, если бы кто-то здесь пошел другим путем.

• Хук предварительной фиксации, который проверяет любые окончания строки lf (или, возможно, все окончания строки lf) и отклоняет их в этом случае.
• Сценарий установки, распространяемый среди разработчиков, который заполняет глобальный конфиг «как есть, как есть».

PS Когда я писал это, мне пришло в голову, что первоначальное преобразование из svn в git может зафиксировать путь по умолчанию, и пока люди придерживаются значения по умолчанию, это также будет довольно плавным. Будучи разработчиком, использующим git в магазине .NET, который установил git с нестандартным «как есть, как есть», я тоже создал там свои собственные проблемы (все они по умолчанию свернули по умолчанию до моего прибытия) , Так что я все еще склоняюсь к какому-то механизму принуждения.

Чтобы ответить на вопрос о том, как внедрить что-то локально, вы не можете без какого-либо очень тяжелого поднятия управления и контроля состояния каждой рабочей станции разработчиков, и я обычно придерживаюсь мнения, что разработчики, вероятно, должны быть локальными администраторами в своей разработке. машина, потому что если нет, то они просто потратят свое время на то, чтобы понять, как получить эти привилегии.

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

Если это так, то вы не должны принимать слияния, которые, как вы упоминали, ломают окончания строк crlf / lf. Таким образом, вы применяете это, когда какой-то другой клиент пытается подтолкнуть вас к изменениям, используя логику на стороне сервера, которая отклоняет запрос на загрязнение вашего репо своими потенциально нарушающими стилистическими решениями.

Нам необходим процесс проверки с использованием запросов Pull в github на наши основные ветки dev или master. В ходе этого процесса обзора мы помечаем запросы на извлечение как требующие изменений, если во многих файлах есть пробелы или различия в конце строк, и настаиваем на том, чтобы они следовали форматированию ветки dev или master, для которой они выполняют запрос на извлечение.

Есть также несколько хороших инструментов, которые зависят от того, какие языки вы используете и какие инструменты CI вы используете, которые могут, в процессе сборки или на этапе запроса на выборку, автоматически форматировать код на основе установленных вами правил. Это также помогает поддерживать целостность кода и минимизировать проблемы с форматированием при фиксации кода.

Вы можете использовать конфигурацию для каждого репозитория, чтобы переопределить конфигурацию пользователя для каждого репозитория. Когда это делается на репо, который считается центральным источником, он должен распространяться с клонами и вытягивать на другие репо, включая локальные, таким образом централизованно переопределяя локальный конфиг.

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

Используя шаблоны в вашем git init, вы можете быть уверены, что ваши репозитории созданы равными со всеми файлами gitignore, gitattributes и т. Д. Именно так, как вы этого хотите.

Последнее, что не имеет прямого отношения к вашему вопросу, я обнаружил, что самое большое трение при переводе команды svn saavy в рабочий процесс на основе git - это то, что они привыкли к дополнительному репо в середине. Я обнаружил, что этот лист визуальной подсказки помог немного объяснить, какая команда имела какое влияние на какую часть.

Надеюсь, это немного помогло.