Git для новичков: рабочие настройки без будущей боли

Git обычно начинают использовать с двух команд: git config --global user.name и git config --global user.email. Для одного человека и одного контура этого достаточно. Проблемы начинаются позже, когда на одной машине появляются личные, рабочие, учебные и клиентские репозитории.

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

Раздели каталоги проектов

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

mkdir -p ~/projects/personal

mkdir -p ~/projects/work

На Windows идея та же самая: держи рабочие и личные checkout-ы в разных корнях, например D:/work/ и D:/personal/. Смешанный каталог вроде D:/projects/ быстро превращается в источник случайных коммитов не той личностью.

Оставь в глобальном конфиге минимум

В ~/.gitconfig можно оставить дефолт для личных проектов и подключить рабочий файл через includeIf:

[user]
  name = Ivan Petrov
  email = ivan@example.com

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

Завершающий / в gitdir:~/projects/work/ важен: Git воспринимает это условие как префикс пути к каталогу .git. Без явной границы легко получить совпадения шире, чем ты ожидал.

Вынеси рабочую личность отдельно

Рабочий конфиг хранит только то, что отличается от личного контура:

[user]
  name = Ivan Petrov
  email = ivan.petrov@company.example

Если контуров больше, добавь столько includeIf, сколько нужно: компания, open source, учебные репозитории, клиентские проекты. Главное - не превращать один глобальный конфиг в смесь всех ролей.

Проверь, откуда взялась настройка

Перед первым коммитом в новом дереве проверь не только значение, но и файл-источник:

git config user.email

git config --show-origin user.email

git config --show-origin user.name

--show-origin показывает, какой именно конфиг дал значение. Это лучше, чем смотреть на итоговый email и гадать, почему он применился.

Разведи SSH-ключи

Если личный и рабочий аккаунт используют разные SSH-ключи, раздели их через ~/.ssh/config и host alias:

Host github-personal
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_personal
  IdentitiesOnly yes

Host github-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_work
  IdentitiesOnly yes

После этого remote можно сделать явным:

git remote set-url origin git@github-work:company/app.git

git remote -v

Так Git-identity и SSH-identity не будут жить в разных реальностях: рабочий каталог включает рабочий email, а remote использует рабочий ключ.

Что стоит вынести в контурный конфиг

• user.name и user.email.
• user.signingkey, если подпись коммитов отличается по контурам.
• commit.gpgsign или gpg.format, если в компании требуется подпись.
• core.sshCommand, если удобнее привязать SSH-ключ прямо в Git-конфиге, а не через host alias.
• Локальные алиасы, если они безопасны только в конкретном рабочем процессе.

Чеклист перед первым коммитом

• git status --short --branch - ты в правильной ветке и видишь только ожидаемые изменения.
• git config --show-origin user.email - email пришел из правильного файла.
• git remote -v - remote указывает на нужный аккаунт и организацию.
• git branch --show-current - имя ветки не случайное.
• git diff --check - нет лишних пробелов и простых formatting-ошибок.

Чего не делать

Не переключай глобальный email руками перед каждым коммитом. Это держится только на памяти и ломается в самый неудобный момент. Не исправляй проблему post-commit хуками, если ее можно решить штатной конфигурацией. Не смешивай личные и рабочие checkout-ы в одном каталоге, если хочешь, чтобы includeIf оставался понятным.