Я думаю, что некоторые из нас, возможно, прошли через это. Вы создаете свою первую учетную запись Git, первый проект, первое репозиторий, устанавливаете Git и начинаете учиться использовать контроль версий в своих проектах разработки программного обеспечения. Вы продолжаете изучать коммиты, ветки, слияния, запросы на включение (!!!), конфликты 😡 и так далее. Но в какой-то момент процесса вы видите / вам нужно использовать / ваш друг просит вас поработать над репозиторием на другом хостинге Git. Например, мы сначала начали на GitHub, но друг попросил нас сделать совместный проект на GitLab.

Как только вы клонируете репозиторий из другого сервиса, вы начинаете делать свои дела и достигаете той части, в которую хотите внести свои изменения. Сделав это, вы переходите к репозиторию и видите…

Это одна из моих рабочих учетных записей Git, которая используется!

После того, как я начал свой первый реальный опыт работы в компании, стало ясно, что в какой-то момент мне придется столкнуться с управлением как рабочими, так и личными учетными записями Git. У меня под рукой есть личная учетная запись Git, потому что иногда я все еще ссылаюсь на часть кода, написанного ранее. Хотя до этого у меня действительно была похожая проблема. Вместо моей рабочей учетной записи Git я переключался между двумя личными учетными записями Git, которые у меня были на GitHub и GitLab.

В настоящее время я работаю с 3 разными учетными записями Git в своей рабочей области:

  • Личный аккаунт на GitHub
  • Рабочий аккаунт GitLab
  • Рабочий аккаунт GitHub

После поиска того, как правильно обрабатывать все без необходимости вручную изменять конфигурации, я думаю, что дошел до воспроизводимого процесса. Все начинается с использования SSH!

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

ssh-keygen -t ed25519 -C “[email protected]” -f “ed25519_personal”
ssh-keygen -t ed25519 -C “[email protected]” -f “ed25519_work_gl”
ssh-keygen -t ed25519 -C “[email protected]” -f “ed25519_work_gh”

-t определяет алгоритм генерации ключа (в данном случае ed25519)

-C добавляет комментарий в конце ключа, чтобы помочь вам различать ключи (тег)

-f указывает имя файла для ключа (по умолчанию сохраняется в `~/.ssh/`)

После этого мы должны запустить ssh-агент в фоновом режиме, который будет обрабатывать операции SSH на нашей локальной машине.

eval "$(ssh-agent -s)"

С этого момента мы можем добавить все закрытые ключи в ssh-agent.

ssh-add ~/.ssh/ed25519_personal
ssh-add ~/.ssh/ed25519_work_gl
ssh-add ~/.ssh/ed25519_work_gh

Совет. По моему опыту, мне нужно запускать ssh-агент и добавлять ключи для каждого сеанса терминала. Поэтому я добавил их в свой .zshrc, чтобы автоматизировать процесс.

# ssh-agent
{ eval `ssh-agent -s` } &>/dev/null
{ ssh-add ~/.ssh/id_ed25519 } &>/dev/null
{ ssh-add ~/.ssh/id_ed25519_personal } &>/dev/null
{ ssh-add ~/.ssh/id_ed25519_gh } &>/dev/null

Теперь, когда мы загрузили все ключи в ssh-agent, пришло время добавить их в GitHub и GitLab соответственно. Поскольку пользовательский интерфейс может измениться для этой части процесса, я сначала дам ссылку на документацию GitHub и GitLab.

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

# Mac
pbcopy < ~/.ssh/ed25519_personal

# Windows
clip < ~/.ssh/ed25519_personal

Для GitHub перейдите к Пользователь > Настройки > Ключи SSH и GPG > Новый ключ SSH.

Здесь вы можете добавить название ключа в качестве своего рода метки к месту хранения этого ключа (например, рабочий ноутбук). В качестве типа ключа оставьте значение Ключ аутентификации. Наконец, вы можете вставить содержимое открытого ключа, которое было скопировано ранее, и нажать «Добавить ключ SSH». Теперь у вас есть этот ключ на GitHub!

Для GitLab перейдите к User > Preferences > SSH Keys.

Шаги почти такие же, как и в GitHub, но здесь вы можете указать определенную дату истечения срока действия ключа для большей безопасности. После вставки содержимого открытого ключа нажмите «Добавить ключ», и теперь вы настроены на получение ключа на GitLab!

Повторите этот процесс для всех ключей соответствующих поставщиков услуг Git.

Мы еще не закончили настройку SSH. В настоящее время с моей настройкой 2 учетных записей GitHub и 1 учетной записи GitLab операции Git, выполняемые для репозиториев GitLab, будут работать без особых проблем. Однако две учетные записи GitHub будут конфликтовать друг с другом. Чтобы решить эту проблему, создайте и измените файл config для операций SSH.

Этот config файл установит правила конфигурации SSH для разных провайдеров и укажет им, какой файл идентификации использовать для каждого домена. Сначала мы создадим и начнем изменять файл конфигурации с помощью этих команд терминала:

cd ~/.ssh/
touch config
nvim config  // Opens the file in Neovim | use your preferred editor

Здесь мы делаем соответствующие записи для всех наших учетных записей Git. Для моей установки это будет означать:

# Personal account
Host github.com
 Hostname github.com
 User git
 IdentityFile ~/.ssh/ed25519_personal

# Work GitLab account
Host gitlab.com
 Hostname gitlab.com
 User git
 IdentityFile ~/.ssh/ed25519_work_gl

# Work GitHub account
Host github.com-work
 Hostname github.com
 User git
 IdentityFile ~/.ssh/ed25519_work_gh

Обратите внимание, что первые две записи имеют схожие конфигурации, но с другим доменом Hostname. Однако последняя запись имеет другую настройку. Хост установлен на github.com-work. Сам хост используется для различения разных учетных записей Git. Используя нотацию github.com-work, ssh-agent будет использовать ключ последней записи для любого URL-адреса Git, который использует эту конкретную нотацию.

Мы можем проверить, все ли настроено правильно, проверив SSH-соединение для каждой из наших учетных записей Git.

ssh -T [email protected]

ssh -T [email protected]

ssh -T [email protected]

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

Если бы это было из моей рабочей учетной записи GitHub, я бы изменил команду на git clone [email protected]:digaji/digaji.git, чтобы отразить имя хоста, определенное в конфигурации SSH.

Однако мы еще не закончили. Поскольку SSH настроен правильно, Git по-прежнему не может различать имя пользователя и адрес электронной почты наших разных учетных записей Git.

«Ручной, но раздражающий» способ справиться с этим — просто изменить конфигурацию Git для каждой папки/репозитория, над которым вы работаете, с помощью этих команд терминала:

git config user.name “<your_username>”
git config user.email “<your_git_email>”

Это означает, что вы изменяете локальную конфигурацию Git для репозитория, над которым вы работаете. Однако это будет означать, что вам придется изменить user.name и user.email в каждом из ваших репозиториев, которые используют учетную запись Git, отличную от вашей глобальной конфигурации Git. Это может сильно разочаровать, когда вы забудете сделать этот начальный шаг и отправите фиксацию с неправильной учетной записью Git (и когда вы просто не хотите беспокоиться об этом вообще!).

Давайте сначала проанализируем, что на самом деле происходит за кулисами этих команд. Когда вы впервые инициализируете Git, настроив user.name и user.email с глобальным флагом, вы создаете основной файл .gitconfig, расположенный в корневом каталоге. Посмотреть содержимое которых можно командой cat ~/.gitconfig

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

После некоторого копания в Интернете оказалось, что есть гораздо более простой способ справиться с этой проблемой.

Попробуем изобразить это на иллюстрации:

  • Основная Code папка
  • Work/FC Папка внутри Code Папка
  • Work/FC-GH Папка внутри Code Папка

Для всех репозиториев в этой конкретной папке Work/FC мы хотим, чтобы рабочая учетная запись GitLab использовалась для всех коммитов и команд Git. Для всех репозиториев в этой конкретной папке Work/FC-GH мы хотим, чтобы рабочая учетная запись GitHub использовалась для всех коммитов и команд Git. Для всех других каталогов на нашем компьютере мы просто хотим использовать нашу личную учетную запись Git. Это когда мы настраиваем наш основной файл .gitconfig.

В официальной документации git-config говорится, что существует метод условного включения другого файла .gitconfig в зависимости от каталога, в котором локально хранятся ваши репозитории Git. Это делается через переменную includeIf.<condition>.path.

В этом примере мы добавляем переменную includeIf вместе с каталогом Git или gitdir из папки Work/FC. После этого добавляем переменную path и указываем путь к .gitconfig для нашего рабочего Git-аккаунта. Затем все, что осталось сделать, это указать user.name и user.email нашей рабочей учетной записи Git.

Повторите для папки Work/FC-GH.

Есть и другие условные операторы, которые вы можете использовать, но использование gitdir кажется самым простым способом для этого варианта использования.

И теперь ко всем репозиториям Git внутри папки Work/FC будет добавлена ​​рабочая конфигурация Git.

Вот и все! Свяжитесь со мной, если есть какие-либо вещи, которые я мог указать неправильно в этой статье. Спасибо и «счастливого» Git-ing!

Я разместил все команды и пошаговые инструкции в этом GitHub gist.

Рекомендации