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

За 20–30 минут вы настроите Git так, чтобы рабочие репозитории использовали один аккаунт, а личные — другой. Коммиты будут получать правильное имя и email, а подключение к GitHub или GitLab будет выбирать нужный SSH-ключ по адресу репозитория.

Что понадобится до начала

• Git 2.13 или новее: именно в этой версии появились условные подключения конфигурации через includeIf.
• Терминал: Terminal в macOS и Linux или Git Bash в Windows.
• Доступ к рабочему и личному аккаунтам на хостинге Git.
• Права добавить SSH-ключи в настройках этих аккаунтов.
• Две отдельные почты, если рабочий и личный профиль должны отличаться в истории коммитов.

Примеры ниже используют GitHub и каталоги ~/work/ и ~/personal/. Для GitLab или другого сервиса меняется имя хоста, но схема остаётся той же.

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

Главная ошибка в такой настройке — разделить только email. Если SSH-ключ остаётся общим, Git всё равно может подключаться не к тому аккаунту.

Шаг 1. Проверьте версию Git и создайте каталог ключей

Выполните:

git --version
mkdir -p ~/.ssh
chmod 700 ~/.ssh

Если Git старше 2.13, обновите его с официального сайта или через менеджер пакетов вашей системы. В Windows каталог .ssh можно создать вручную в домашней папке пользователя, если команда mkdir недоступна.

Проверка: первая команда выводит версию Git, а каталог ~/.ssh существует. На Windows путь обычно находится внутри C:\Users\ИмяПользователя.

Шаг 2. Создайте два SSH-ключа

Не используйте один ключ для всех аккаунтов. Создайте отдельные ключи с понятными именами:

ssh-keygen -t ed25519 -C "work@example.com" -f ~/.ssh/id_ed25519_work
ssh-keygen -t ed25519 -C "personal@example.com" -f ~/.ssh/id_ed25519_personal

Команда попросит задать парольную фразу. Лучше задать её для обоих ключей. В результате появятся четыре файла: два закрытых ключа без расширения и два открытых с суффиксом .pub.

Проверка:

ls -l ~/.ssh/id_ed25519_work ~/.ssh/id_ed25519_work.pub
ls -l ~/.ssh/id_ed25519_personal ~/.ssh/id_ed25519_personal.pub

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

Шаг 3. Добавьте открытые ключи в аккаунты

Выведите содержимое открытых ключей:

cat ~/.ssh/id_ed25519_work.pub
cat ~/.ssh/id_ed25519_personal.pub

Скопируйте первую строку в настройки рабочего аккаунта GitHub: Settings → SSH and GPG keys → New SSH key. Вторую строку добавьте в личный аккаунт. Не перепутайте подписи ключей и не вставляйте файлы без .pub.

Для GitLab или другого сервиса откройте раздел SSH Keys в настройках профиля. Названия пунктов могут отличаться, но добавляется именно открытый ключ.

Проверка: оба ключа отображаются в соответствующих аккаунтах. Сам факт появления ключа в списке ещё не проверяет выбор нужного ключа — это будет на следующем шаге.

Шаг 4. Создайте псевдонимы SSH-хостов

Откройте файл конфигурации SSH:

nano ~/.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

Host — локальный псевдоним, а HostName — настоящий адрес сервиса. Параметр IdentitiesOnly yes запрещает SSH перебирать другие ключи из агента и снижает риск входа не в тот аккаунт.

Сохраните файл и задайте права:

chmod 600 ~/.ssh/config

Проверка подключения:

ssh -T git@github-work
ssh -T git@github-personal

GitHub обычно отвечает сообщением вроде Hi USERNAME! You've successfully authenticated. Сессия оболочки при этом не открывается — это нормальное поведение. В ответе должны быть разные имена аккаунтов. Если сервис сообщил об успешной аутентификации, но имя одинаковое, проверьте, в какой аккаунт добавлены ключи.

Шаг 5. Разделите имя и email в Git

Создайте два файла конфигурации. Для рабочего профиля:

nano ~/.gitconfig-work

[user]
    name = Рабочее Имя
    email = work@example.com

Для личного профиля:

nano ~/.gitconfig-personal

[user]
    name = Личное Имя
    email = personal@example.com

Теперь подключите их к основному файлу Git через условие по каталогу:

nano ~/.gitconfig

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

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

Важно сохранить завершающий слеш в gitdir:~/work/ и gitdir:~/personal/. Git применит рабочий профиль только к репозиториям внутри соответствующего дерева каталогов.

Проверка: выполните вне репозитория:

git config --global --list --show-origin

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

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

Псевдоним из SSH-конфига нужно указать в URL. Для рабочего репозитория:

mkdir -p ~/work
cd ~/work
git clone git@github-work:company/project.git

Для личного:

mkdir -p ~/personal
cd ~/personal
git clone git@github-personal:my-user/project.git

Проверка в каждом каталоге:

git config user.name
git config user.email
git remote -v

В рабочем каталоге должны отображаться рабочие имя и email, а в адресе удалённого репозитория — github-work. В личном каталоге — личные данные и github-personal.

Если репозиторий уже клонирован

Перенесите его в правильное дерево каталогов или измените URL удалённого репозитория. Например:

cd ~/work/project
git remote set-url origin git@github-work:company/project.git
git config user.name
git config user.email

Если репозиторий лежит в другом месте, можно задать автора только внутри него:

git config user.name "Рабочее Имя"
git config user.email "work@example.com"

Такой параметр записывается в .git/config и имеет приоритет над глобальными настройками. Это удобный аварийный вариант, но для большого числа проектов надёжнее единая структура каталогов и includeIf.

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

Ошибка «Permission denied (publickey)»

Сервис не принял ни один ключ. Проверьте, что открытый ключ полностью скопирован в нужный аккаунт, а в ~/.ssh/config правильно указаны IdentityFile и HostName. Запустите проверку с подробным выводом:

ssh -vT git@github-work

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

SSH подключает не тот аккаунт

Чаще всего причина — отсутствие IdentitiesOnly yes или неправильный URL remote. Выполните git remote -v и убедитесь, что используется github-work или github-personal, а не обычный github.com.

В коммите отображается старый email

Проверьте источник настройки:

git config --show-origin --get user.email
git config --show-origin --get user.name

Если значение пришло из .git/config, локальная настройка перекрывает условный профиль. Удалите её командой git config --unset user.email и повторите проверку. Уже созданный коммит сам по себе не изменится.

Условный профиль не включается

Проверьте физический путь репозитория и совпадение с шаблоном. Репозиторий в ~/Work/project может не совпасть с правилом для ~/work/ в окружениях с чувствительностью к регистру. Также убедитесь, что основной файл действительно находится в домашнем каталоге и называется .gitconfig.

Что важно проверить перед первым push

1. Выполните git config user.email и сравните адрес с аккаунтом, от имени которого должен появиться коммит.
2. Выполните git remote -v и проверьте SSH-псевдоним.
3. Проверьте доступ без изменения проекта: ssh -T git@github-work или ssh -T git@github-personal.
4. Не добавляйте в репозиторий файлы из ~/.ssh. В Git должен попадать только открытый ключ, если это прямо требуется документацией или автоматизацией.

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

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