IT и данные

Git для нескольких аккаунтов: настройка до первого коммита

Дмитрий Ершов — IT-архитектор, инфобезопасностьОпубликовано 14 октября 2026 · 7 мин чтенияСоставлено с опорой на практику

Один Git на рабочие и личные проекты часто заканчивается коммитом не с того адреса или push в чужой аккаунт. Ниже — безопасная схема с отдельными SSH-ключами, алиасами и автоматическим выбором профиля.

Git для нескольких аккаунтов: настройка до первого коммита

Один Git может отправлять код в рабочий GitHub, личный GitLab и корпоративный сервер без постоянного ввода паролей. Но только если заранее разделить три вещи: имя и email автора коммита, SSH-ключ для входа и URL удалённого репозитория. Эта инструкция рассчитана на Git 2.40 и новее, OpenSSH 8 и новее и занимает около 20–30 минут.

Что нужно иметь до начала

Подготовьте установленный Git, доступ к аккаунтам и права на создание SSH-ключей. Команды ниже подходят для macOS и Linux. В Windows 10/11 используйте Git Bash или встроенный OpenSSH; пути с ~ в Git Bash означают домашнюю папку пользователя.

Git 2.40 или новее. Версию проверьте командой git --version.
Две папки для проектов, например ~/work и ~/personal.
Рабочий и личный email, которые должны попасть в историю коммитов.
Доступ к настройкам SSH на компьютере и возможность добавить публичный ключ в каждый сервис.
Пустые или уже существующие репозитории, для которых вы настраиваете профили.

Проверка: команда git --version выводит установленную версию, а папки для проектов существуют и доступны на запись.

SSH отвечает на вопрос «кто может отправить код», а Git-конфигурация — «чьим именем подписан коммит». Один ключ не задаёт автора коммита автоматически.

Шаг 1. Разложите проекты по папкам

Автоматический выбор профиля проще всего привязать к пути репозитория. Поэтому рабочие проекты кладите под один каталог, а личные — под другой.

Создайте каталоги:
```
mkdir -p ~/work ~/personal
```
Если каталоги уже есть, команда ничего не удалит.

Проверка: выполните ls -ld ~/work ~/personal. Обе строки должны указывать на существующие каталоги.

Шаг 2. Создайте отдельные SSH-ключи

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

Создайте рабочий ключ:
```
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_work -C 'YOUR_WORK_EMAIL'
```
На запрос passphrase задайте отдельную парольную фразу. Не сохраняйте приватный ключ в облачном диске и не отправляйте файл без расширения .pub другим людям.

Проверка: появились файлы ~/.ssh/id_ed25519_work и ~/.ssh/id_ed25519_work.pub.
Создайте личный ключ:
```
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_personal -C 'YOUR_PERSONAL_EMAIL'
```
Имя файла должно отличаться от рабочего, иначе новый ключ может перезаписать старый.

Проверка: в ~/.ssh есть обе пары файлов, а приватные файлы имеют права, ограничивающие доступ владельцем.
Запустите агент и добавьте ключи:
```
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519_work
ssh-add ~/.ssh/id_ed25519_personal
```
В Windows Git Bash агент может быть уже запущен. Если ssh-add сообщает, что не может подключиться к агенту, запустите службу OpenSSH Authentication Agent средствами Windows или используйте агент, который поставляется с вашим менеджером паролей.

Проверка: ssh-add -l показывает два отпечатка ключей, а не сообщение The agent has no identities.

Шаг 3. Свяжите имена SSH с нужными ключами

SSH по умолчанию обращается к одному имени хоста, например github.com. Алиасы позволяют сделать два разных адреса: github-work и github-personal. В URL репозитория затем будет видно, какой ключ используется.

Создайте или откройте файл ~/.ssh/config:
```
Host github-work
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_work
    IdentitiesOnly yes

Host github-personal
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_personal
    IdentitiesOnly yes
```
Отступы перед параметрами должны быть пробелами или табуляцией. Параметр IdentitiesOnly yes запрещает SSH перебирать другие ключи из агента и снижает риск входа не в тот аккаунт.

Проверка: выполните ssh -G github-work и найдите в выводе identityfile ~/.ssh/id_ed25519_work. Для второго алиаса должен отображаться личный ключ.
Скопируйте публичные ключи и добавьте их в соответствующие аккаунты:
```
cat ~/.ssh/id_ed25519_work.pub
cat ~/.ssh/id_ed25519_personal.pub
```
Добавляйте содержимое рабочего файла только в рабочий аккаунт, личного — только в личный. В публичном ключе одна длинная строка, начинающаяся с ssh-ed25519.

Проверка: команда ssh -T git@github-work подтверждает аккаунт рабочего сервиса, а ssh -T git@github-personal — личный. Точный текст ответа зависит от сервиса; сообщение о том, что shell-доступ запрещён, само по себе не означает ошибку, если сервис узнал пользователя.

Шаг 4. Настройте имя автора автоматически

SSH определяет право на push, но не меняет поля Author и Committer. Их задаёт Git. Условные подключения includeIf выбирают файл конфигурации по пути репозитория.

Откройте глобальный файл Git:
```
git config --global --edit
```
Добавьте в него:
```
[includeIf "gitdir:~/work/"]
    path = ~/.gitconfig-work

[includeIf "gitdir:~/personal/"]
    path = ~/.gitconfig-personal
```
Окончательный слеш важен: он указывает Git применять правило ко всем репозиториям внутри каталога.

Проверка: git config --global --list --show-origin показывает два блока includeIf.
Создайте профиль для рабочих репозиториев:
```
cat > ~/.gitconfig-work <<'EOF'
[user]
    name = YOUR_WORK_NAME
    email = YOUR_WORK_EMAIL
EOF
```
Создайте личный профиль:
```
cat > ~/.gitconfig-personal <<'EOF'
[user]
    name = YOUR_PERSONAL_NAME
    email = YOUR_PERSONAL_EMAIL
EOF
```
В Windows Git Bash эти команды работают как показано. В обычном PowerShell создайте файлы вручную и вставьте те же секции.

Проверка: из каталога ~/work выполните git config user.email, затем из ~/personal. Команды должны вывести разные адреса.

Сноска. includeIf — условительное подключение файла конфигурации Git. Правило не меняет настройки уже открытого терминала и не анализирует содержимое проекта: оно смотрит на путь к каталогу репозитория.

Шаг 5. Клонируйте репозитории через правильный алиас

Обычный URL git@github.com:owner/repository.git обходит созданные алиасы и может выбрать не тот ключ. Используйте имя из SSH-конфигурации.

Для рабочего проекта выполните:
```
cd ~/work
git clone git@github-work:WORK_OWNER/WORK_REPOSITORY.git
```
Для личного:
```
cd ~/personal
git clone git@github-personal:PERSONAL_OWNER/PERSONAL_REPOSITORY.git
```
Замените владельца и репозиторий на реальные значения, но оставьте github-work или github-personal.

Проверка: войдите в каталог проекта и выполните:
```
git remote -v
git config user.name
git config user.email
```
В удалённом URL должен быть нужный алиас, а имя и email — соответствовать этому профилю.
Для уже клонированного репозитория исправьте URL:
```
git remote set-url origin git@github-work:WORK_OWNER/WORK_REPOSITORY.git
```
Если проект лежит не под ~/work или ~/personal, условное правило не сработает. Временно задайте профиль только для этого репозитория:
```
git config --local user.name 'YOUR_WORK_NAME'
git config --local user.email 'YOUR_WORK_EMAIL'
```
Проверка: git config --show-origin --get-regexp '^(user\.|remote\.origin\.url$)' показывает источник каждого значения и правильный URL.

Если не получилось

Permission denied (publickey). Сервис не принял ключ. Проверьте, что публичный ключ добавлен в нужный аккаунт, а в ~/.ssh/config совпадают имя алиаса и путь к приватному ключу. Для подробного журнала используйте ssh -vT git@github-work, не публикуя вывод целиком: в нём могут быть локальные пути и имена.
Вход выполняется не в тот аккаунт. Обычно URL содержит github.com, а не созданный алиас, или отсутствует IdentitiesOnly yes. Исправьте URL командой git remote set-url origin и снова проверьте ssh -T.
Коммит подписан неправильным email. Git взял локальную настройку репозитория или не совпал путь с правилом gitdir. Выполните git config --show-origin --get-regexp '^user\.' и удалите ошибочное локальное значение командой git config --local --unset-all user.email, если оно больше не нужно.
fatal: not a git repository. Проверка выполняется не внутри проекта. Перейдите в каталог, где находится папка .git, либо запустите команду после клонирования.
Could not open a connection to your authentication agent. SSH-агент не запущен в текущей сессии. Запустите агент для своей ОС и повторите ssh-add; сами ключи при этом создавать заново не нужно.

Что сделать дальше

Создайте тестовый коммит в каждом профиле и проверьте его автора до отправки в удалённый репозиторий. Затем добавьте проверку в рабочий процесс: перед первым push смотрите на git remote -v и git log -1 --format='%an <%ae>'. Если проекты нельзя разложить по каталогам, используйте локальные настройки user.name и user.email в каждом репозитории, а SSH-алиасы оставьте без изменений.

Не хотите разбираться сами?

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

Спросить за 60 ₽

Источники: Git documentation: git-config, GitHub Docs: Managing multiple accounts

Частые вопросы

Можно ли использовать один SSH-ключ для всех аккаунтов?

Технически многие сервисы позволяют добавить один публичный ключ в несколько аккаунтов, но это ухудшает изоляцию. При отзыве ключа или утечке придётся менять доступ сразу везде. Отдельный ключ на аккаунт проще контролировать.

Почему email в коммите не меняется после настройки SSH?

SSH проверяет доступ к удалённому репозиторию, а автора коммита задают параметры Git user.name и user.email. Эти настройки независимы. Проверьте источник значения командой git config --show-origin --get-regexp '^user\.'

Что делать, если я уже сделал коммит с неправильным аккаунтом?

Если коммит ещё не отправлен, автора последнего коммита можно исправить через git commit --amend --reset-author после настройки правильного профиля. Если коммит уже опубликован, переписывание истории затронет других разработчиков, поэтому сначала согласуйте способ исправления с командой.

Можно ли настроить несколько аккаунтов без SSH, через HTTPS?

Да, но тогда нужно отдельно управлять учётными данными и credential helper, а URL не будет явно показывать выбранный SSH-алиас. Для двух и более аккаунтов SSH обычно проще диагностировать. Правила хранения токенов зависят от операционной системы и сервиса.

Что будет, если я не успею настроить профили до первого push?

Push может пройти, если выбранный ключ имеет доступ, но коммит всё равно останется с тем email, который Git использовал в момент создания. Исправить последний неотправленный коммит обычно можно, а опубликованную историю безопасно менять только после согласования с командой.

Почему includeIf не сработал для уже существующего проекта?

Проверьте точный путь к репозиторию и правило gitdir:~/work/. Репозиторий должен находиться внутри соответствующей папки, а локальная настройка user.name или user.email может иметь приоритет над подключённым файлом. Источник значения показывает команда git config --show-origin.

Материал носит информационный характер и подготовлен редакцией «Агентуры». Он не является офертой, рекламой или индивидуальной консультацией. Упомянутые продукты, компании и торговые знаки принадлежат их правообладателям. Перед принятием решений, влекущих юридические или финансовые последствия, обратитесь к профильному специалисту.

Ещё по теме

Расширения VS Code для базы данных и работы с Git6 мин чтения Подсветка и форматирование в VS Code: короткое руководство5 мин чтения Подсветка и форматирование в VS Code: разбор на примере7 мин чтения Подсветка и форматирование в VS Code: что настроить заранее6 мин чтения Git для нескольких аккаунтов: частые ошибки настройки6 мин чтения Как настроить Git для нескольких аккаунтов: пошаговая инструкция7 мин чтения