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

После создания репозитория GitHub с адресом электронной почты автора, который определенно не предназначен для использования для публикации с открытым исходным кодом, и, следовательно, потратив больше времени на использование «git filter-branch», чем он чувствует себя комфортно, автор попытался найти техническое решение для свои недостатки. Эта статья документирует и делится результатами этого квеста.

Стандартная установка Git

Стандартная документация по установке Git, будь то Git [1] или GitHub [2], глобально определяет имя пользователя и адрес электронной почты с помощью двух следующих команд:

git config --global user.name "Michael Pellaton"
git config --global user.email [email protected]

Чтобы получить доступ к вышестоящим репозиториям Git с помощью SSH, эти источники говорят вам создать SSH-ключ по умолчанию, если он не существует, и зарегистрировать соответствующий закрытый ключ в вышестоящем диспетчере репозиториев, таком как GitHub или Bitbucket.

Вызовы

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

  • Используйте рабочую электронную почту, чтобы использовать только рабочие репозитории, и используйте личную электронную почту для всех материалов с открытым исходным кодом.
  • В качестве подрядчика используйте электронную почту клиента для коммитов в его репозитории.
  • Используйте логин для рабочих репозиториев и свое настоящее имя для репозиториев с открытым исходным кодом.
  • Иметь разные несовместимые требования к ключу SSH.
  • Необходимость использовать autocrlf=true для одного клиента и false для другого.

Старое решение

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

Сценарии переключения идентичности
Идея этого решения состоит в том, чтобы иметь сценарий оболочки, который управляет глобальной конфигурацией Git для каждой организации, в которой вы работаете. Все, что вам нужно сделать, это запустить соответствующий сценарий. Преимущество этого подхода в том, что все зависящие от организации вещи централизованы в одном месте, и клонирование дополнительного репозитория или изменение значения при необходимости очень просто. Однако недостаток забывчивого разработчика остается - и поверьте мне, удаление неподходящих адресов электронной почты и имен пользователей из репозитория GitHub с помощью git filter-branch и принудительного нажатия [3] тоже не приносит удовольствия.

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

identity-github.sh:
#!/bin/bash
git config --global user.name "Michael Pellaton"
git config --global user.email [email protected]
git config --global commit.template ~/.gitmessage.github
git config --global core.autocrlf true
export GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa.github"
echo "Git identity switched to: GitHub"
git config user.name
git config user.email

Новые функции Git спешат на помощь

Условные включения
Совсем недавно, в мае 2017 года, Git представил «условные включения» в выпуске 2.13 [4]. Всякий раз, когда Git читает файл .gitconfig - что в основном для каждой команды - он оценивает условие и решает, включать ли другой файл конфигурации или нет. Переменные конфигурации в этом дополнительном файле имеют приоритет над значениями, уже определенными в конфигурациях восходящего потока до момента включения (как если бы включенные значения были встроены в точку включения.

Базовая форма условного включения - includeIf.<condition>.path, и в настоящее время поддерживаются следующие два условия [5]:

  • gitdir:PATTERN сопоставляет расположение репозитория с указанным шаблоном глобуса. Если он совпадает, условие включения выполнено.
  • gitdir/i: то же, что и gitdir, но без учета регистра

В следующем примере .gitconfig.foo включается только в том случае, если текущий репозиторий git находится внутри ~/foo/:

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

С помощью этой новой функции мы можем избавиться от сценариев переключения идентичности, просто проверив репозитории каждой организации, с которой мы работаем, в отдельном подкаталоге. Затем условный оператор include автоматически применяет соответствующую конфигурацию для каждой операции git. Прошли те дни, когда вы забыли вручную переключать идентификаторы Git или настраивать каждый репозиторий после клонирования \ o /.

Переменная конфигурации core.sshCommand
Версия 2.10 Git (сентябрь 2016 г.) представила переменную конфигурации core.sshCommand [6]. Указанная команда выполняется вместо стандартного ssh в операциях выборки и выталкивания.

Значение переменной среды GIT_SSH_COMMAND имеет приоритет над core.sshCommand, и поэтому мы должны убедиться, что оно больше не установлено, прежде чем использовать последнее в условно импортированной конфигурации.

Новое решение

Основной файл конфигурации Git теперь содержит все общие и резервные настройки, а также дополнительные файлы конфигурации в зависимости от места извлечения в репозитории:

~/.gitconfig:
# common and fallback configurations
[user]
    name = Michael Pellaton
    email = [email protected]
[core]
    sshCommand = ssh -i ~/.ssh/id_rsa.private
[color]
    ui = auto
# conditional configurations for github repos
[includeIf “gitdir:~/git/github/”]
    path = .gitconfig.github
# conditional configuration for work repos
[includeIf “gitdir:~/git/work/”]
    path = .gitconfig.work

Файл условного включения применяется ко всем репозиториям, клонированным под ~/git/github, с переопределениями для имени пользователя, электронной почты и ключа SSH:

~/.gitconfig.github:
[user]
    email = [email protected]
[core]
    sshCommand = ssh -i ~/.ssh/id_rsa.github

И в заключение, файл условного включения применяется ко всем репозиториям, клонированным в ~/git/work рабочих настройках:

~/.gitconfig.work:
[user]
    name = some.weird.work.username
    email = [email protected]
[core]
    sshCommand = ssh -i ~/.ssh/id_rsa.work

Заключение

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

События, инициированные извне, такие как базовая установка (нового) персонального компьютера, являются хорошим поводом для того, чтобы тщательно изучить настройку наших инструментов разработки и найти лучшие решения проблем, которые мы считали «решенными» в прошлый раз.

использованная литература

[1] https://git-scm.com/book/en/v1/Getting-Started-First-Time-Git-Setup
[2] https://help.github.com/ категории / настройка /
[3] https://help.github.com/articles/changing-author-info/
[4] https://github.com/blog/ 2360-git-2-13-has-made
[5] https://git-scm.com/docs/git-config#_conditional_includes
[6] https: //stackoverflow.com/a/38474137