Git: управление несколькими аккаунтами

Логотип Git

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

Как Git хранит данные об аккаунтах
Управление учётными данными для нескольких аккаунтов

Короткое определение

Локальный репозиторий — это копия проекта на вашем компьютере. Git управляет только локальными данными; сервер используется при push/pull.

Как Git обрабатывает аккаунты

Git сам по себе полностью локален: ваш репозиторий находится на компьютере, а сервер (GitHub, GitLab и т. п.) подключается только при push/pull. При сетевых операциях применяются настройки пользователя из конфигурации Git и учётные данные (пароль, токен или SSH-ключ).

Коротко — Git учитывает:

user.name — отображаемое имя автора коммитов;
user.email — email, привязанный к коммитам;
учётные данные для аутентификации (HTTPS: логин/токен, SSH: ключ).

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

Глобальная и локальная конфигурация

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

git config --global user.name "username"

git config --global user.email "email@example.com"

Чтобы задать имя и email только для конкретного репозитория (и не ломать глобальные настройки), выполните те же команды без флага –global из каталога репозитория:

git config user.name "username"

git config user.email "email@example.com"

Локальная конфигурация хранится в .git/config репозитория и имеет приоритет над глобальной. Рекомендация: держите в глобальной конфигурации аккаунт, которым вы пользуетесь чаще всего, а для проектов с другим аккаунтом задавайте локальные настройки.

Важно: смена глобального конфига изменит поведение всех репозиториев без локальной конфигурации.

Управление учётными данными для нескольких аккаунтов

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

Короткие варианты:

Использовать один SSH-ключ на машине и добавить его в оба аккаунта (личный и рабочий).
Или создать отдельный SSH-ключ для каждого аккаунта и настроить ~/.ssh/config с Host-алиасами.

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

Преимущества нескольких ключей: чёткое разграничение доступа по аккаунтам и лёгкость ротации ключей.

Генерация дополнительного SSH-ключа (пример)

Рекомендуется использовать ed25519 или RSA (если необходимо). Пример команды:

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

Эта команда создаст пару ключей id_ed25519_work и id_ed25519_work.pub.

Добавьте публичный ключ (содержимое id_ed25519_work.pub) в настройки SSH-ключей вашего удалённого аккаунта (GitHub/GitLab/Bitbucket).

Загрузка ключей в ssh-agent

Чтобы ssh-agent автоматически использовал ключи при запуске терминала, добавьте в профиль оболочки команду:

ssh-add ~/.ssh/id_ed25519_work

Если не использовать агент, придётся указывать ключ вручную с флагом -i при каждой SSH-операции.

ssh -i ~/.ssh/id_ed25519_work git@github.com

Настройка ~/.ssh/config с Host-алиасами

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

# Личный аккаунт — стандартный хост
Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519

# Рабочий аккаунт — алиас github-work
Host github-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_work

Обратите внимание: в Host нельзя использовать двоеточие. Чтобы обратиться к рабочему аккаунту в remote URL, используйте форму:

git@github-work:company/repo.git

Тогда SSH будет использовать ключ, указанный в секции Host github-work. Это проще и безопаснее, чем постоянно менять ключи вручную.

Примечание: если у вас уже есть remote с URL git@github.com:username/repo.git, замените github.com на github-work в URL для репозиториев, которые должны использовать рабочий ключ.

Пример изменения remote URL для уже клонированного репозитория

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

После этого push/pull будут выполняться с использованием секции github-work из ~/.ssh/config.

Расширенные советы и ситуации

Когда можно использовать один ключ

Если вы работаете на личном ноутбуке и компании позволяют добавлять персональные ключи.
Если нет строгой политики по разделению доступов.

Когда не стоит этого делать:

Компания требует отдельную аутентификацию или аудит доступа.
Нужно быстро отозвать доступ конкретного аккаунта без изменения доступа с машины.

Отладка проблем с SSH

Используйте ssh -T -v git@github.com или ssh -T -v git@github-work чтобы увидеть, какой ключ отправляется и какие сообщения возвращает сервер.
Проверьте права на файл ключа: ~/.ssh/id_* должны быть с правами 600.
Убедитесь, что публичный ключ добавлен в нужный аккаунт на сервере.

Работа с HTTPS

HTTPS использует токены (personal access tokens) и менеджеры учётных данных. Если вы используете HTTPS и разные аккаунты, удобнее держать разные ключи/учётные записи в менеджере ключей или использовать git credential helper, но обычно SSH проще для мульти-аккаунтов.

Практическая пошаговая методика (мини-SOP)

Решите: один ключ на машину или несколько ключей.
Если нужен второй ключ — сгенерируйте его: ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_work.
Добавьте публичный ключ в нужный аккаунт на сервере.
Добавьте ключ в ssh-agent: ssh-add ~/.ssh/id_ed25519_work.
Откройте ~/.ssh/config и пропишите Host-алиас для рабочего аккаунта.
Для репозитория измените remote URL: git remote set-url origin git@github-work:company/repo.git.
Установите локальные git-настройки в репозитории: git config user.name “Work Name” и git config user.email “work@example.com”.
Проверьте: ssh -T git@github-work и git push.

Чеклист для ролей

Для разработчика:

Сгенерировать ключ и добавить в аккаунт.
Настроить ~/.ssh/config.
Изменить remote URL в репозитории.
Установить локальные user.name и user.email.
Проверить push/pull.

Для администратора/менеджера безопасности:

Политика rotации ключей и отзыва доступа.
Инструкции для сотрудников по генерации ключей.
Аудит зарегистрированных публичных ключей в аккаунтах.

Типичные ошибки и их решения

Неправильный Host в ~/.ssh/config — проверьте соответствие alias и URL.
Неправильные права на файлы ключей — установите chmod 600 ~/.ssh/id_*
Ключ не добавлен в аккаунт на сервере — откройте публичный ключ и вставьте в интерфейс GitHub/GitLab.
Используете глобальный git-config вместо локального — задайте настройки без –global в нужном репозитории.

Краткое резюме

Используйте локальные git-конфиги и SSH-ключи, чтобы избежать конфликтов между аккаунтами. Один ключ на машину — проще; несколько ключей и Host-алиасы в ~/.ssh/config — гибче и безопаснее для разделения личного и рабочего доступа.

Важно: всегда проверяйте, какой ключ и какие учётные данные используются, с помощью ssh -v и git remote -v.

Если нужна проверка вашей конфигурации — приложите вывод ssh -T -v и содержимое ~/.ssh/config; я помогу проанализировать и подсказать правки.