Освоение настройки пользователя Git: имя, email и редактор по умолчанию

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

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

Понимание уровней конфигурации Git

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

Существует три основных уровня конфигурации:

Системный уровень (--system): Применяется к каждому пользователю и каждому репозиторию на всей машине. Редко используется для идентификации пользователя, если только не управляется выделенный сервер сборки.
Глобальный уровень (--global): Применяется ко всем репозиториям текущего пользователя на машине. Здесь вы обычно устанавливаете свои основные user.name и user.email.
Локальный уровень (--local): Применяется только к конкретному репозиторию, в котором вы находитесь. Это позволяет использовать другую идентификацию для конкретного проекта (например, рабочий vs. личный).

Просмотр текущих настроек конфигурации

Перед внесением изменений полезно посмотреть, что Git в настоящее время настроен использовать. Вы можете вывести список настроек для всех уровней или только для конкретного:

# Просмотр всех настроек на всех уровнях
git config --list

# Просмотр только глобальных настроек
git config --global --list

Настройка вашей пользовательской идентификации (имя и email)

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

1. Установка глобальной пользовательской идентификации

Для большинства пользователей установка имени и email глобально является рекомендуемым первым шагом. Это гарантирует, что все ваши будущие проекты будут иметь эту идентификацию по умолчанию. Замените заполнители на вашу фактическую информацию.

Установка имени:

git config --global user.name "Ваше Полное Имя"

Установка email:

Настоятельно рекомендуется использовать email-адрес, связанный с вашей учетной записью GitHub/GitLab/Bitbucket, особенно если вы используете SSH-ключи или подпись коммитов.

git config --global user.email "ваш[email protected]"

Лучшая практика: Используйте точный email-адрес, привязанный к вашему хостинг-провайдеру, чтобы гарантировать правильное отображение вкладов на удаленных платформах.

2. Переопределение идентификации для конкретного репозитория (локальный уровень)

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

Перейдите в корневую директорию репозитория и выполните команды конфигурации без флага --global:

# Перейдите в директорию вашего проекта
cd ~/projects/client-project-alpha

# Установите конкретное имя для этого репозитория
git config user.name "Рабочее Имя"

# Установите конкретный email для этого репозитория
git config user.email "рабочий[email protected]"

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

Как Git выбирает идентификацию

Когда Git обрабатывает коммит, он проверяет уровни в порядке: Локальный -> Глобальный -> Системный. Первая настройка, которую он находит для user.name или user.email, и будет использована.

Настройка текстового редактора по умолчанию

Когда Git требует ввода от вас — например, при написании сообщения коммита, инструкции для rebase или заметки о разрешении конфликта слияния — он открывает настроенный текстовый редактор. По умолчанию это может быть базовый терминальный редактор, такой как vi или vim, что может быть сложно для новых пользователей.

Установка глобальной предпочтительной редактора

Вы можете настроить Git на использование вашего предпочтительного редактора во всех ваших машинах или проектах с помощью флага --global.

Использование VS Code в качестве редактора

Если вы предпочитаете Visual Studio Code и у вас установлена интеграция с командной строкой (code), установите его следующим образом:

git config --global core.editor "code --wait"

Флаг --wait критически важен; он говорит Git приостановить выполнение, пока вы не закроете файл, открытый в VS Code, гарантируя, что сообщение коммита будет завершено.

Использование Sublime Text в качестве редактора

Для пользователей Sublime Text:

git config --global core.editor "subl -n -w"

Использование Nano или Vim (если уже знакомы)

Если вы предпочитаете простой терминальный редактор:

# Для Nano
git config --global core.editor "nano"

# Для Vim (часто по умолчанию)
git config --global core.editor "vim"

Тестирование вашей конфигурации редактора

Самый простой способ проверить, работает ли ваша конфигурация редактора, — это инициировать amend, требующий сообщения, или создать коммит без флага -m:

# Создайте фиктивный файл и попробуйте сделать коммит без -m
touch tempfile.txt
git add tempfile.txt
git commit 
# Это должно открыть ваш недавно настроенный редактор.

Исправление существующей неправильной идентификации

Изменение user.name и user.email влияет на будущие коммиты. Оно не переписывает уже существующие коммиты. Если ваш последний коммит имеет неправильного автора и вы еще не отправили его, вы можете исправить его после исправления конфигурации:

git config user.name "Правильное Имя"
git config user.email "правильный[email protected]"
git commit --amend --reset-author

Если плохой коммит уже отправлен в общую ветку, будьте осторожны. Переписывание опубликованной истории может нарушить работу других людей. Для частной ветки amend и force push могут быть приемлемы:

git push --force-with-lease

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

Проверка, откуда пришло значение

Когда Git ведет себя странно, git config --list может быть слишком шумным. Используйте --show-origin, чтобы Git сообщил, какой файл предоставил каждое значение:

git config --show-origin --list

Вы можете увидеть вывод, подобный этому:

file:/Users/alex/.gitconfig    [email protected]
file:.git/config               [email protected]

Это означает, что локальное значение репозитория побеждает в текущем репозитории. Это самый быстрый способ диагностировать "Я изменил свой глобальный email, но Git все еще использует старый".

Вы также можете запросить одно значение:

git config --show-origin user.email

Рабочая и личная настройка, которая работает

Распространенный шаблон — сохранить личную глобальную идентификацию и переопределять рабочие репозитории локально:

git config --global user.name "Алекс Ривера"
git config --global user.email "[email protected]"

cd ~/work/payments-api
git config user.email "[email protected]"

Некоторые команды предпочитают отдельные клоны в отдельных директориях. Более новые версии Git поддерживают условные включения, которые могут автоматически загружать рабочую конфигурацию для репозиториев по пути:

# ~/.gitconfig
[user]
    name = Алекс Ривера
    email = [email protected]

[includeIf "gitdir:~/work/"]
    path = ~/.gitconfig-work

# ~/.gitconfig-work
[user]
    email = [email protected]

Правила сопоставления точных путей могут быть немного неожиданными на разных платформах, поэтому протестируйте это внутри реального репозитория:

cd ~/work/some-repo
git config --show-origin user.email

Проблемы с редактором, которых можно избежать

Настройка core.editor в основном важна, когда Git нуждается в сообщении или файле инструкций: коммиты слияния, интерактивные rebase, исправления коммитов и коммиты без -m. Если Git открывает Vim, и вы не чувствуете себя там комфортно, может показаться, что команда зависла.

Для VS Code флаг --wait не является опциональным:

git config --global core.editor "code --wait"

Без --wait Git может открыть файл и немедленно продолжить, прежде чем вы закончите писать сообщение. Для терминальных серверов nano часто менее удивителен:

git config --global core.editor "nano"

Вы можете протестировать редактор без создания реального изменения в проекте:

git commit --allow-empty

Напишите тестовое сообщение, сохраните, а затем удалите пустой коммит, если он вам не нужен:

git reset --soft HEAD~1

Подпись коммитов и учетные записи хостинга

Ваш email в Git отделен от аутентификации. SSH-ключи, персональные токены доступа и вход в браузере решают, можете ли вы отправлять изменения. user.email определяет, какой email автора будет записан в объект коммита.

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

git config --global user.email "[email protected]"

Если ваша организация требует подписанные коммиты, идентификация — это только одна часть настройки. Вам также могут понадобиться user.signingkey, commit.gpgsign или настройка подписи SSH. Держите это отдельно от базовой настройки имени/email, чтобы вы могли отлаживать один слой за раз.

Автор, коммиттер и переопределения окружения

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

Вы можете увидеть оба поля с помощью:

git log --format=fuller -1

Этот вывод полезен, когда кто-то говорит "Git использовал неправильный email", но обычный однострочный лог показывает только автора. Коммиттер может быть другим, потому что мейнтейнер применил патч или потому что rebase воссоздал коммит.

Git также может читать идентификацию из переменных окружения:

GIT_AUTHOR_NAME="Build Bot" \
GIT_AUTHOR_EMAIL="[email protected]" \
git commit -m "Обновить сгенерированные файлы"

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

env | rg '^GIT_(AUTHOR|COMMITTER)'

Сбросьте случайные переопределения перед коммитом:

unset GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL

Небольшая политика команды, предотвращающая грязную историю

Для команд лучшая политика настройки пользователя Git обычно короткая:

Используйте свое настоящее имя или тот же псевдоним, который ваша команда узнает.
Используйте корпоративный email для корпоративных репозиториев.
Используйте подтвержденный email хостинг-провайдера, чтобы коммиты привязывались к правильной учетной записи.
Не переписывайте общую историю только для очистки старых метаданных автора, если команда не согласна.
Документируйте предпочтительный core.editor только если ваши скрипты онбординга зависят от него.

Вы можете добавить проверку pre-commit или pre-push для доменов email, но сохраняйте дружелюбие. Локальный хук, блокирующий каждый коммит, потому что кто-то работает в паре с другой машины, создаст трения. Политика на стороне сервера или проверка CI на защищенных ветках обычно проще в управлении.

Вот простая локальная проверка, которую вы можете выполнить вручную перед отправкой рабочего кода:

git config user.email
git log --format='%h %ae %s' origin/main..HEAD

Если какой-либо коммит показывает личный email в корпоративной ветке, исправьте это перед открытием pull request. Это намного проще, чем исправлять объединенную ветку позже.

Устранение распространенных сюрпризов конфигурации

Если git config --global user.email показывает правильное значение, но коммиты все еще используют что-то другое, проверьте, находитесь ли вы внутри репозитория с локальным переопределением:

git config --local user.email
git config --show-origin user.email

Если локальное значение неверно, замените его или сбросьте:

git config user.email "[email protected]"
git config --unset user.email

Сброс локального значения заставляет Git вернуться к глобальному значению. Это часто чище, чем устанавливать одно и то же значение в каждом репозитории.

Если Git говорит Author identity unknown, это означает, что Git не смог найти используемые user.name и user.email из конфигурации или окружения. Установите оба, а не только один:

git config --global user.name "Алекс Ривера"
git config --global user.email "[email protected]"

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

Быстрый чеклист

Используйте git config --global для настроек, которые применяются везде, таких как ваша идентификация по умолчанию и редактор.
Используйте git config (без флагов) внутри репозитория для локального переопределения глобальных настроек.
Используйте git config --show-origin --list, когда вам нужно знать, какой файл побеждает.
Используйте git commit --amend --reset-author только когда перезапись последнего коммита уместна.
Используйте --wait при настройке графических редакторов, чтобы Git ждал завершения редактирования.