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

Личный коммит может попасть в рабочий репозиторий с неправильным email, а push — уйти не в тот аккаунт. Причина обычно в том, что Git хранит автора коммита отдельно от способа входа на GitHub или другой хостинг. Для Git 2.x покажем, как разделить настройки по папкам, выбрать SSH-ключ для каждого аккаунта и проверить, что именно использует репозиторий.

Сначала разделите две настройки

user.name и user.email записываются в коммит как данные автора. Сами по себе они не выбирают аккаунт для push. Аутентификацию определяют удалённый адрес репозитория и способ подключения: SSH-ключ либо сохранённые HTTPS-учётные данные.

Поэтому настройка только email решает лишь половину задачи. Можно подписывать коммиты рабочим адресом, но отправлять их через личный аккаунт — или наоборот.

Настраивайте отдельно две вещи: кто указан автором коммита и каким аккаунтом вы проходите аутентификацию при отправке.

Термин. Remote, или удалённый репозиторий, — адрес, записанный в настройке вроде origin. При push Git подключается именно по этому адресу, а не по адресу из user.email.

Три способа разделить аккаунты

Чаще всего нужны вместе второй и третий варианты: папка задаёт автора, а SSH-алиас — аккаунт для подключения. Для HTTPS вместо SSH выбирайте нужную учётную запись в менеджере учётных данных; правила для SSH-ключей к этому способу не относятся.

Автор коммита: задайте профиль для каталогов

Пример ниже рассчитан на macOS, Linux или Git Bash и Git 2.13 или новее: в этих версиях доступны условные подключения конфигурации через includeIf. Пусть рабочие проекты находятся в ~/work/, личные — в ~/personal/.

В глобальном файле ~/.gitconfig добавьте:

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

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

Создайте файл ~/.gitconfig-work с рабочими данными:

[user]
    name = Ваше имя
    email = work@example.com

В ~/.gitconfig-personal укажите личные имя и email. Папки в примере — условие выбора: репозитории должны находиться внутри соответствующего каталога. После этого проверьте настройки из папки конкретного проекта:

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

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

Для одного-двух проектов проще задать автора прямо в каждом репозитории. Выполните внутри него:

git config user.name "Ваше имя"
git config user.email "work@example.com"

Команды без --global меняют конфигурацию только текущего репозитория. Проверка та же: команда git config --show-origin --get user.email покажет применённое значение.

SSH: направьте каждый remote на свой ключ

Этот вариант нужен, если на одном хостинге у вас несколько аккаунтов и вы подключаетесь по SSH. Создайте отдельные ключи для аккаунтов; не копируйте один приватный ключ между рабочими и личными устройствами. Команды ниже предназначены для Unix-подобного терминала и Git Bash:

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 в настройки безопасности нужных аккаунтов. Приватные файлы без .pub никому не отправляйте.

Добавьте в ~/.ssh/config алиасы. Здесь оба аккаунта размещены на GitHub; для другого хостинга замените имя сервера на адрес своего сервиса.

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

Теперь укажите нужный алиас в адресе remote. Для рабочего репозитория команда выглядит так:

git remote set-url origin git@github-work:ORG/REPO.git

Замените ORG/REPO на владельца и имя репозитория. Для личного проекта используйте git@github-personal:.... Проверка: git remote -v должен показать алиас, а не обычный github.com. Затем выполните ssh -T git@github-work: хостинг должен подтвердить, какой аккаунт прошёл аутентификацию. Для GitHub ожидайте приветствие с именем аккаунта; интерактивной командной оболочки он не предоставляет.

Ошибки, из-за которых настройка не работает

• Изменили email и ждёте другой аккаунт при push. Email задаёт автора коммита, а не способ входа. Проверьте git remote -v и настройку SSH или HTTPS.
• Добавили ключ, но оставили обычный адрес хоста. Remote вида git@github.com:... не указывает алиас из примера. Замените адрес на git@github-work:... или другой нужный алиас.
• SSH предлагает не тот ключ. Проверьте соответствие IdentityFile нужному аккаунту и наличие IdentitiesOnly yes. Текст Permission denied (publickey). означает, что сервер не принял предложенную аутентификацию: проверьте добавленный публичный ключ, алиас и права доступа к репозиторию.
• В рабочей папке применяется личный email. Сначала проверьте, где лежит каталог .git, затем посмотрите источник значения командой git config --show-origin --get user.email. Условие includeIf зависит от пути к репозиторию.
• Настроили SSH, но подключаетесь по HTTPS. Алиасы из SSH-конфига не управляют адресом https://.... Либо поменяйте remote на SSH, либо отдельно выберите нужный аккаунт в менеджере учётных данных.

Когда какой способ выбирать

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

Если вы используете HTTPS, не добавляйте SSH-ключи «на всякий случай»: проверьте remote и настройте менеджер учётных данных для своего хостинга. Детали входа зависят от операционной системы, клиента и настроек сервиса.

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

Проверьте один рабочий и один личный репозиторий: командой git config --show-origin --get user.email — автора, а командой git remote -v — способ подключения. Перед первым push убедитесь, что SSH-тест подтверждает нужный аккаунт, а в удалённом репозитории у него есть доступ. Затем повторите проверку для проектов, которые лежат вне привычных папок: именно там условная настройка чаще всего даёт неожиданный результат.