Credential helper git что это

Использование диспетчера учетных данных Git для проверки подлинности в Azure Repos

Диспетчер учетных данных Git упрощает проверку подлинности с помощью репозиториев Git Azure Repos. Диспетчеры учетных данных позволяют использовать те же учетные данные, что и для веб-портала Azure DevOps Services. Диспетчеры учетных данных поддерживают многофакторную проверку подлинности с помощью учетной записи Майкрософт или идентификатора Microsoft Entra. Помимо поддержки многофакторной проверки подлинности с помощью Azure Repos, диспетчеры учетных данных также поддерживают двухфакторную проверку подлинности с помощью репозиториев GitHub.

Azure Repos обеспечивает IDE для учетной записи Майкрософт и проверки подлинности Microsoft Entra с помощью следующих клиентов:

• Team Explorer в Visual Studio
• IntelliJ и Android Studio с подключаемым модулем Azure Repos для IntelliJ

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

Установка диспетчера учетных данных Git

Windows

Скачайте и запустите последний установщик Git для Windows, который включает диспетчер учетных данных Git. Обязательно включите параметр установки диспетчера учетных данных Git.

macOS и Linux

Вы можете использовать ключи SSH для проверки подлинности в Azure Repos или использовать диспетчер учетных данных Git.

Инструкции по установке включены в репозиторий GitHub для GCM. В Mac рекомендуется использовать Homebrew. В Linux можно установить из deb или tarball.

Использование диспетчера учетных данных Git

При первом подключении к репозиторию Git из клиента Git диспетчер учетных данных запрашивает учетные данные. Укажите учетную запись Майкрософт или учетные данные Microsoft Entra. Если у вашей учетной записи включена многофакторная проверка подлинности, диспетчер учетных данных также предложит вам пройти этот процесс.

После проверки подлинности диспетчер учетных данных создает и кэширует личный маркер доступа для будущих подключений к репозиторию. Команды Git, которые подключаются к этой учетной записи, не будут запрашивать учетные данные пользователя до истечения срока действия маркера. Маркер можно отозвать с помощью Azure Repos.

Получение справки

Вы можете открыть и сообщить о проблемах с диспетчером учетных данных Git в проекте GitHub.

7.14 Инструменты Git — Хранилище учётных данных

Если для подключения к удалённым серверам вы используете протокол SSH, то вы можете использовать ключ вместо пароля, что позволит вам безопасно передавать данные без ввода логина и пароля. Однако, это невозможно при использовании HTTP-протоколов — каждое подключение требует пары логин, пароль. Всё ещё сложнее для систем с двухфакторной аутентификацией, когда выражение, которое вы используете в качестве пароля, генерируется случайно и его сложно воспроизвести.

К счастью, в Git есть система управления учётными данными, которая может помочь в этом. В Git «из коробки» есть несколько опций:

• По умолчанию Git не кеширует учётные данные совсем. Каждое подключение будет запрашивать у вас логин и пароль.
• В режиме «cache» учётные данные сохраняются в памяти в течение определённого периода времени. Ни один из паролей никогда не сохраняется на диск и все они удаляются из кеша через 15 минут.
• В режиме «store» учётные данные сохраняются на неограниченное время в открытом виде в файле на диске. Это значит что, до тех пор пока вы не измените пароль к Git-серверу, вам не потребуется больше вводить ваши учётные данные. Недостатком такого подхода является то, что ваш пароль хранится в открытом виде в файле в вашем домашнем каталоге.
• На случай если вы используете Mac, в Git есть режим «osxkeychain», при использовании которого учётные данные хранятся в защищённом хранилище, привязанному к вашему системному аккаунту. В этом режиме учётные данные сохраняются на диск на неограниченное время, но они шифруются с использованием той же системы, с помощью которой сохраняются HTTPS-сертификаты и автозаполнения для Safari.
• В случае если вы используете Windows, то можете включить использование «Git Credential Manager» во время установки Git для Windows или установить крайнюю версию GCM как отдельный сервис. Он похож на «osxkeychain», описанный выше, но для управления секретной информацией использует Windows Credential Store. Его так же можно использовать в WSL1 и WSL2. Больше имнформации об установке и настройке GCM можно найти на странице проекта на GitHub.

Вы можете выбрать один из этих методов, изменив настройки Git:

$ git config --global credential.helper cache

Некоторые из этих помощников имеют опции. Помощник «store» может принимать аргумент —file , который определяет где будет хранится файл с открытыми учётными данный (по умолчанию используется ~/.git-credentials ). Помощник «cache» принимает опцию —timeout , которая изменяет промежуток времени, в течение которого демон остаётся запущенным (по умолчанию «900», или 15 минут). Ниже приведён пример как вы можете настроить помощник «store» на использование определённого файла:

$ git config --global credential.helper 'store --file ~/.my-credentials'

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

[credential] helper = store --file /mnt/thumbdrive/.git-credentials helper = cache --timeout 30000

Под капотом

Как же это всё работает? Корневой командой Git для системы помощников авторизации является git credential , которая принимает команду через аргумент, а все остальные входные данные через стандартный поток ввода.

Возможно, это проще понять на примере. Допустим, помощник авторизации был настроен и в нём сохранены учётные данные для mygithost . Ниже приведена рабочая сессия, в которой используется команда «fill», вызываемая Git при попытке найти учётные данные для сервера:

$ git credential fill (1) protocol=https (2) host=mygithost (3) protocol=https (4) host=mygithost username=bob password=s3cre7 $ git credential fill (5) protocol=https host=unknownhost Username for 'https://unknownhost': bob Password for 'https://bob@unknownhost': protocol=https host=unknownhost username=bob password=s3cre7

1. Это команда, которая начинает взаимодействие.
2. После этого Git-credential ожидает данные из стандартного потока ввода. Мы передаём ему то, что знаем: протокол и имя сервера.
3. Пустая строка обозначает, что ввод закончен и система управления учётными данными должна ответить, что ей известно.
4. После этого Git-credential выполняет какую-то работу и выводит обнаруженную информацию.
5. Если учётные данные не найдены, Git спрашивает у пользователя логин/пароль, и выводит их обратно в задействованный поток вывода (в данном примере это одна и та же консоль).

В действительности, система управления учётными данными вызывает программы, отделённые от самого Git; какие и как зависит в том числе и от настроек credential.helper . Существует несколько вариантов вызова:

Выполняется git-credential-foo -a —opt=bcd

Выполняется /absolute/path/foo -xyz

Код после символа ! выполняется в шелле

Итак, помощники, описанные выше на самом деле называются git-credential-cache , git-credential-store и т. д. и мы можем настроить их на приём аргументов командной строки. Общая форма для этого git-credential-foo [args] . Протокол ввода/вывода такой же как и у git-credential, но они используют немного другой набор операций:

• get запрос логина и пароля.
• store запрос на сохранение учётных данных в памяти помощника.
• erase удаляет учётные данные для заданных параметров из памяти используемого помощника.

Для операций store и erase не требуется ответа (в любом случае Git его игнорирует). Однако, для Git очень важно, что помощник ответит на операцию get . Если помощник не знает что-либо полезного, он может просто завершить работу не выводя ничего, но если знает — он должен добавить к введённой информации имеющуюся у него информацию. Вывод обрабатывается как набор операций присваивания; выведенные значения заменят те, что Git знал до этого.

Ниже приведён пример, используемый ранее, но вместо git-credential напрямую вызывается git-credential-store:

$ git credential-store --file ~/git.store store (1) protocol=https host=mygithost username=bob password=s3cre7 $ git credential-store --file ~/git.store get (2) protocol=https host=mygithost username=bob (3) password=s3cre7

1. Здесь мы просим git-credential-store сохранить некоторые учётные данные: логин «bob» и пароль «s3cre7», которые будут использоваться при доступе к https://mygithost .
2. Теперь мы извлечём эти учётные данные. Мы передаём часть уже известных нам параметров подключения ( https://mygithost ) и пустую строку.
3. git-credential-store возвращает логин и пароль, которые мы сохранили ранее.

Ниже приведено содержимое файла ~/git.store :

https://bob:s3cre7@mygithost

Это просто набор строк, каждая из которых содержит URL, включающий в себя учётные данные. Помощники osxkeychain и wincred используют форматы, лежащие в основе их хранилищ, а cache использует его собственный формат хранения во внутренней памяти (который другие процессы прочитать не могут).

Собственное хранилище учётных данных

Поскольку git-credential-store и подобные ей утилиты являются отдельными от Git программами, не сложно сделать так, чтобы любая программа могла быть помощником авторизации Git. Помощники, предоставляемые Git, покрывают наиболее распространённые варианты использования, но не все. Для примера допустим, что ваша команда имеет некоторые учётные данные, совместно используемые всей командой, например, для развёртывания. Эти данные хранятся в общедоступном каталоге, но вы не хотите копировать их в ваше собственное хранилище учётных данных, так как они часто изменяются. Ни один из существующих помощников не покрывает этот случай; давайте посмотрим, что будет стоить написать свой собственный. Есть несколько ключевых особенностей, которым должна удовлетворять эта программа:

1. Мы должны уделить внимание только одной операции get ; store и erase являются операциями записи, поэтому мы не будем ничего делать при их получении.
2. Формат файла с совместно используемыми учётными данными такой же как и у git-credential-store .
3. Расположение этого файла более-менее стандартное, но, на всякий случай, мы должны позволять пользователям передавать свой собственный путь.

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

#!/usr/bin/env ruby require 'optparse' path = File.expand_path '~/.git-credentials' # (1) OptionParser.new do |opts| opts.banner = 'USAGE: git-credential-read-only [options] ' opts.on('-f', '--file PATH', 'Specify path for backing store') do |argpath| path = File.expand_path argpath end end.parse! exit(0) unless ARGV[0].downcase == 'get' # (2) exit(0) unless File.exists? path known = <> # (3) while line = STDIN.gets break if line.strip == '' k,v = line.strip.split '=', 2 known[k] = v end File.readlines(path).each do |fileline| # (4) prot,user,pass,host = fileline.scan(/^(.*?):\/\/(.*?):(.*?)@(.*)$/).first if prot == known['protocol'] and host == known['host'] and user == known['username'] then puts "protocol=#" puts "host=#" puts "username=#" puts "password=#" exit(0) end end

1. Здесь мы разбираем аргументы командной строки, позволяя указывать пользователям входной файл. По умолчанию это ~/.git-credentials .
2. Эта программа отвечает только если операцией является get и файл хранилища существует.
3. В цикле считываются данные из стандартного ввода, до тех пор пока не будет прочитана пустая строка. Введённые данные для дальнейшего использования сохраняются в отображении known .
4. Этот цикл читает содержимое файла хранилища, выполняя поиск соответствия. Если протокол и сервер из known соответствуют текущей строке, программа выводит результат и завершает работу.

Мы сохраним нашего помощника как git-credential-read-only , поместим его в один из каталогов, содержащихся в списке PATH , а так же сделаем его исполняемым. Ниже приведено на что будет похож сеанс взаимодействия:

$ git credential-read-only --file=/mnt/shared/creds get protocol=https host=mygithost protocol=https host=mygithost username=bob password=s3cre7

Так как его имя начинается с «git-», мы можем использовать простой синтаксис для настройки:

$ git config --global credential.helper 'read-only --file /mnt/shared/creds'

Как вы видите, расширять эту систему довольно просто и это позволяет решить некоторые общие проблемы, которые могут возникнуть у вас и вашей команды.

Что нам стоит Git настроить!

Дарова, хабр! (ничего оригинальнее не придумал)

Сомневаюсь что эта заметка тянет на полноценный пост, но я все же оставлю ее здесь. О чем же пойдет речь?

Все мы слышали о Git. Все мы знаем что он — хорош. Но лишь немногие пытаются что-то с ним делать, как-то его протвикерить. Сразу говорю, тут не будет ничего паранормального, только немного работы с файлом .gitconfig. Да-да, именно с тем файлом, который так трепетно пылится у вас в домашней директории.

Так, мне уже немного надоело писать этот, по сути, бессмысленный вступительный текст, так что давайте уже начнем что-то делать.

Что такое .gitconfig и зачем он нужен?

В стандартной поставке системы контроля версий Git есть замечательный файл — .gitconfig. Его предназначение очевидно из названия. Строго говоря, это пользовательский конфиг. Он позволяет настраивать алиасы, надстройки, etc.

Не знаю как на других системах, но в Linux он лежит в ~. Если его там нету — смело создавайте!

Открываем .gitconfig в удобном для вас текстовом редакторе (для меня это nano).

Подсветка вывода

Читать вывод Git’а «всухую» достаточно сложно. Я видел достаточно много людей которые терпели это. После одной замечательной комманды им полегчало. Для включения цветного вывода добавляем строчки в .gitconfig:

[color] ui = true 

Себя записываем

Зачем это нужно? Если вы запустите git log для какого-то репозитория, вы увидите что для каждого коммита, автор характеризируется через Name и Email. Чтобы нас правильно нашли, настало время задать все это правильно. Внимание! Менять эту информацию во время разработки крайне нежелательно. Она может поломать историю (множественные автора)! Желательно единажды выбрать какое-то имя и конкретный Email.

[user] name = Anonymous Doody email = anonymous.doody@anonymous.com 

Шаблон коммитов

Не знаю как другие хабровчане работают, но в основном мои коммиты идут в KDE Edu проекты. Там четко диктуют правила формы и вида коммита, так как он парсится разными ботами и т.д. Чтобы не дай Бог ошибиться или что-то неправильно сделать существуют шаблоны. Такой шаблон очень просто сделать (а можно и взять где-то). Чтобы он отображался во время git commit нужно добавить такое:

[commit] template = ~/.commit-template 

В данном случае, ~/.commit-template конечно же может быть любым файлом в вашей файловой системе.

Credential Helper

Бывает такое что нужно выполнить несколько операций с удаленным репозиторием за раз. Каждый раз вводить имя и пароль, имя и пароль, имя и… Напрягает, нет? Меня напрягает. Начиная с версии 1.7.10 Git поддерживает Credential Helper.

[credential] helper = cache --timeout=

Ставим нужное время (у меня это 3600 — один час) и радуемся!

Алиасы для частых команд

Я очень часто пользуюсь командами checkout и branch, например. Писать по три-четыре раза одно и тоже — надоедает. Давайте заменим их на более лаконичный вариант: cd и dir, например.

[alias] cd = checkout dir = branch mersq = merge --squash free = branch -D 

А теперь посмотрим что мы сделали:

git pull --rebase git branch git checkout temp git add -u git commit git merge master git checkout master git merge --squash temp git commit git push git branch -D temp 

git pull --rebase git dir git cd temp git add -u git commit git merge master git cd master git mersq temp git commit git push git free temp 

Префиксы для remote

Есть один трюк, который нередко используется разработчиками. Это префиксы для remote. Они позволяют сократить длину адреса к удаленному репозиторию. Можно задать такие для read-only и push. Зачем? Это логично для open-source проектов. Для уменшения нагрузки на сервер и скорости, лучше pull’ить из anongit (read-only) без использования SSH. Что стоит у меня для KDE?

[url "http://anongit.kde.org/"] insteadOf = kde: [url "git@git.kde.org:"] pushInsteadOf = kde: 

Давайте разбираться. Тут мы настроили два URL для pull и push. Задали префикс kde. Что это нам дает? Посмотрим на примере (в статье не указан префикс gh — для GitHub):

git clone http://anongit.kde.org/marble git clone https://github.com/user/repository 

git clone kde:marble git clone gh:user/repository 

Стало лучше, не правда ли?

Заключение

В статье были опущены мои всякие «экзотические» алиасы и доп. префиксы для разных сервисов. Смело могу сказать, что после того как потвикерил Git — работать стало приятнее. Все знакомые, которые опробовали это — согласились со мной.

P.S. Если я что-то делаю неправильно или я уже совсем убогий, пожалуйста, отпишите ко мне в ЛС и сообщите/посоветуйте (если вам не сложно, конечно).

UPD: Больше интересного и свежего можно найти тут.

7.14 Инструменты Git – Хранилище учётных данных

Если для подключения к удалённым серверам вы используете протокол SSH, то вместо пароля вы можете использовать ключ, что позволит вам безопасно передавать данные без ввода логина и пароля. Однако это невозможно при использовании HTTP-протоколов – каждое подключение требует пары логин/пароль. Всё ещё сложнее для систем с двухфакторной аутентификацией, когда выражение, которое вы используете в качестве пароля, генерируется случайно, и его сложно воспроизвести.

К счастью, в Git есть система управления учётными данными, которая может помочь в этом. В Git «из коробки» есть несколько опций:

• По умолчанию Git не кеширует учётные данные совсем. Каждое подключение будет запрашивать у вас логин и пароль.
• В режиме «cache» учётные данные сохраняются в памяти в течение определённого периода времени. Ни один из паролей никогда не сохраняется на диск, и все они удаляются из кеша через 15 минут.
• В режиме «store» учётные данные сохраняются на неограниченное время в открытом виде в файле на диске. Это значит что, до тех пор, пока вы не измените пароль к Git-серверу, вам не потребуется больше вводить ваши учётные данные. Недостатком такого подхода является то, что ваш пароль хранится в открытом виде в файле в вашем домашнем каталоге.
• На случай, если вы используете Mac, в Git есть режим «osxkeychain», при использовании которого учётные данные хранятся в защищённом хранилище, привязанному к вашему системному аккаунту. В этом режиме учётные данные сохраняются на диск на неограниченное время, но они шифруются с использованием той же системы, с помощью которой сохраняются HTTPS-сертификаты и автозаполнения для Safari.
• В случае если вы используете Windows, вы можете установить помощник, называемый «Git Credential Manager for Windows». Он похож на «osxkeychain», описанный выше, но для управления секретной информацией использует Windows Credential Store. Найти его можно по ссылке https://github.com/Microsoft/Git-Credential-Manager-for-Windows.

Вы можете выбрать один из этих методов, изменив настройки Git:

$ git config --global credential.helper cache

Некоторые из этих помощников имеют опции. Помощник store может принимать аргумент —file , который определяет, где будет хранится файл с открытыми учётными данными (по умолчанию используется ~/.git-credentials ). Помощник cache принимает опцию —timeout , которая изменяет промежуток времени, в течение которого демон остаётся запущенным (по умолчанию 900 , или 15 минут). Ниже приведён пример, как вы можете настроить помощник store на использование определённого файла:

$ git config --global credential.helper 'store --file ~/.my-credentials'

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

[credential] helper = store --file /mnt/thumbdrive/.git-credentials helper = cache --timeout 30000

Под капотом

Как же это всё работает? Корневой командой Git для системы помощников авторизации является git credential , которая принимает команду через аргумент, а все остальные входные данные – через стандартный поток ввода.

Возможно, это проще понять на примере. Допустим, помощник авторизации был настроен, и в нем сохранены учётные данные для mygithost . Ниже приведена рабочая сессия, в которой используется команда fill , вызываемая Git при попытке найти учётные данные для сервера:

$ git credential fill (1) protocol=https (2) host=mygithost (3) protocol=https (4) host=mygithost username=bob password=s3cre7 $ git credential fill (5) protocol=https host=unknownhost Username for 'https://unknownhost': bob Password for 'https://bob@unknownhost': protocol=https host=unknownhost username=bob password=s3cre7

1. Это команда, которая начинает взаимодействие.
2. После этого Git-credential ожидает данные из стандартного потока ввода. Мы передаём ему то, что знаем: протокол и имя сервера.
3. Пустая строка обозначает, что ввод закончен, и система управления учётными данными должна ответить, что ей известно.
4. После этого Git-credential выполняет какую-то работу и выводит обнаруженную информацию.
5. Если учётные данные не найдены, Git спрашивает у пользователя логин/пароль и выводит их обратно в задействованный поток вывода (в данном примере это одна и та же консоль).

В действительности, система управления учётными данными вызывает программы, отделённые от самого Git; какие и как зависит в том числе и от настроек credential.helper . Существует несколько вариантов вызова:

Настройки	Поведение
foo	Выполняется git-credential-foo
foo -a —opt=bcd	Выполняется git-credential-foo -a —opt=bcd
/absolute/path/foo -xyz	Выполняется /absolute/path/foo -xyz
!f() < echo "password=s3cre7"; >; f	Код после символа ! выполняется в шелле

Итак, помощники, описанные выше, на самом деле называются git-credential-cache , git-credential-store и т.д., и мы можем настроить их на приём аргументов командной строки. Общая форма для этого: git-credential-foo [args] . Протокол ввода/вывода такой же как и у git-credential , но они используют немного другой набор операций:

• get – запрос логина и пароля;
• store – запрос на сохранение учётных данных в памяти помощника;
• erase – удаляет учётные данные для заданных параметров из памяти используемого помощника.

Для операций store и erase не требуется ответа (в любом случае Git его игнорирует). Однако для Git очень важно, что помощник ответит на операцию get . Если помощник не знает что-либо полезного, он может просто завершить работу, не выводя ничего, но если знает – он должен добавить к введённой информации имеющуюся у него информацию. Вывод обрабатывается как набор операций присваивания; выведенные значения заменят те, что Git знал до этого.

Ниже приведён пример, используемый ранее, но вместо git-credential напрямую вызывается git-credential-store :

$ git credential-store --file ~/git.store store (1) protocol=https host=mygithost username=bob password=s3cre7 $ git credential-store --file ~/git.store get (2) protocol=https host=mygithost username=bob (3) password=s3cre7

1. Здесь мы просим git-credential-store сохранить некоторые учётные данные: логин « bob » и пароль « s3cre7 », которые будут использоваться при доступе к https://mygithost .
2. Теперь мы извлечём эти учётные данные. Мы передаём часть уже известных нам параметров подключения ( https://mygithost ) и пустую строку.
3. git-credential-store возвращает логин и пароль, которые мы сохранили ранее.

Ниже приведено содержимое файла ~/git.store :

https://bob:s3cre7@mygithost

Это просто набор строк, каждая из которых содержит URL, включающий в себя учётные данные. Помощники osxkeychain и wincred используют форматы, лежащие в основе их хранилищ, а cache использует его собственный формат хранения во внутренней памяти (который другие процессы прочитать не могут).

Собственное хранилище учётных данных

Поскольку git-credential-store и подобные ей утилиты являются отдельными от Git программами, не сложно сделать так, чтобы любая программа могла быть помощником авторизации Git. Помощники, предоставляемые Git, покрывают наиболее распространённые варианты использования, но не все. Для примера допустим, что ваша команда имеет какие-то учётные данные, совместно используемые всей командой, например, для развёртывания. Эти данные хранятся в общедоступном каталоге, но вы не хотите копировать их в ваше собственное хранилище учётных данных, так как они часто изменяются. Ни один из существующих помощников не покрывает этот случай; давайте посмотрим, что будет стоить написать свой собственный. Есть несколько ключевых особенностей, которым должна удовлетворять эта программа:

1. Мы должны уделить внимание только одной операции get ; store и erase являются операциями записи, поэтому мы не будем ничего делать при их получении.
2. Формат файла с совместно используемыми учётными данными такой же как и у git-credential-store .
3. Расположение это файла более-менее стандартное, но, на всякий случай, мы должны позволять пользователям передавать свой собственный путь.

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

#!/usr/bin/env ruby require 'optparse' path = File.expand_path '~/.git-credentials' # (1) OptionParser.new do |opts| opts.banner = 'USAGE: git-credential-read-only [options] ' opts.on('-f', '--file PATH', 'Specify path for backing store') do |argpath| path = File.expand_path argpath end end.parse! exit(0) unless ARGV[0].downcase == 'get' # (2) exit(0) unless File.exists? path known = <> # (3) while line = STDIN.gets break if line.strip == '' k,v = line.strip.split '=', 2 known[k] = v end File.readlines(path).each do |fileline| # (4) prot,user,pass,host = fileline.scan(/^(.*?):\/\/(.*?):(.*?)@(.*)$/).first if prot == known['protocol'] and host == known['host'] and user == known['username'] then puts "protocol=#" puts "host=#" puts "username=#" puts "password=#" exit(0) end end

1. Здесь мы разбираем аргументы командной строки, позволяя указывать пользователям входной файл. По умолчанию это ~/.git-credentials .
2. Эта программа отвечает, только если операцией является get , и файл хранилища существует.
3. В цикле считываются данные из стандартного ввода до тех пор, пока не будет прочитана пустая строка. Введённые данные для дальнейшего использования сохраняются в отображении known .
4. Этот цикл читает содержимое файла хранилища, выполняя поиск соответствия. Если протокол и сервер из known соответствуют текущей строке, программа выводит результат и завершает работу.

Мы сохраним нашего помощника как git-credential-read-only , поместим его в один из каталогов, содержащихся в списке PATH , а также сделаем его исполняемым. Ниже приведено, на что будет похож сеанс взаимодействия:

$ git credential-read-only --file=/mnt/shared/creds get protocol=https host=mygithost protocol=https host=mygithost username=bob password=s3cre7

Так как его имя начинается с « git- », мы можем использовать простой синтаксис для настройки:

$ git config --global credential.helper 'read-only --file /mnt/shared/creds'

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