Git credential manager for windows что это - Доктор Windows

Git Credential Manager

Git Credential Manager (GCM) is a secure
Git credential helper built on .NET that runs
on Windows, macOS, and Linux. It aims to provide a consistent and secure
authentication experience, including multi-factor auth, to every major source
control hosting service and platform.

GCM supports (in alphabetical order) Azure DevOps, Azure DevOps
Server (formerly Team Foundation Server), Bitbucket, GitHub, and GitLab.
Compare to Git’s built-in credential helpers
(Windows: wincred, macOS: osxkeychain, Linux: gnome-keyring/libsecret), which
provide single-factor authentication support for username/password only.

GCM replaces both the .NET Framework-based
Git Credential Manager for Windows and the Java-based
Git Credential Manager for Mac and Linux.

Install

See the installation instructions for the current version of GCM for
install options for your operating system.

Current status

Git Credential Manager is currently available for Windows, macOS, and Linux*.
GCM only works with HTTP(S) remotes; you can still use Git with SSH:

Azure DevOps SSH
GitHub SSH
Bitbucket SSH

Feature	Windows	macOS	Linux*
Installer/uninstaller	✓	✓	✓
Secure platform credential storage (see more)	✓	✓	✓
Multi-factor authentication support for Azure DevOps	✓	✓	✓
Two-factor authentication support for GitHub	✓	✓	✓
Two-factor authentication support for Bitbucket	✓	✓	✓
Two-factor authentication support for GitLab	✓	✓	✓
Windows Integrated Authentication (NTLM/Kerberos) support	✓	N/A	N/A
Basic HTTP authentication support	✓	✓	✓
Proxy support	✓	✓	✓
`amd64` support	✓	✓	✓
`x86` support	✓	N/A	✗
`arm64` support	best effort	✓	best effort, no packages
`armhf` support	N/A	N/A	best effort, no packages

(*) GCM guarantees support only for the Linux distributions that are officially
supported by dotnet.

Supported Git versions

Git Credential Manager tries to be compatible with the broadest set of Git
versions (within reason). However there are some know problematic releases of
Git that are not compatible.

Git 1.x

The initial major version of Git is not supported or tested with GCM.
Git 2.26.2

This version of Git introduced a breaking change with parsing credential
configuration that GCM relies on. This issue was fixed in commit
12294990 of the Git project, and released in Git
2.27.0.

How to use

Once it’s installed and configured, Git Credential Manager is called implicitly
by Git. You don’t have to do anything special, and GCM isn’t intended to be
called directly by the user. For example, when pushing (git push) to
Azure DevOps, Bitbucket, or GitHub, a
window will automatically open and walk you through the sign-in process. (This
process will look slightly different for each Git host, and even in some cases,
whether you’ve connected to an on-premises or cloud-hosted Git host.) Later Git
commands in the same repository will re-use existing credentials or tokens that
GCM has stored for as long as they’re valid.

Read full command line usage here.

Configuring a proxy

See detailed information here.

Additional Resources

See the documentation index for links to additional resources.

Experimental Features

Windows broker (experimental)

Contributing

This project welcomes contributions and suggestions.
See the contributing guide to get started.

This project follows GitHub’s Open Source Code of Conduct.

License

We’re MIT licensed.
When using GitHub logos, please be sure to follow the
GitHub logo guidelines.

Источник

Git Credential Manager

GCM replaces both the .NET Framework-based
Git Credential Manager for Windows and the Java-based
Git Credential Manager for Mac and Linux.

Install

See the installation instructions for the current version of GCM for
install options for your operating system.

Current status

Git Credential Manager is currently available for Windows, macOS, and Linux*.
GCM only works with HTTP(S) remotes; you can still use Git with SSH:

Azure DevOps SSH
GitHub SSH
Bitbucket SSH

Feature	Windows	macOS	Linux*
Installer/uninstaller	✓	✓	✓
Secure platform credential storage (see more)	✓	✓	✓
Multi-factor authentication support for Azure DevOps	✓	✓	✓
Two-factor authentication support for GitHub	✓	✓	✓
Two-factor authentication support for Bitbucket	✓	✓	✓
Two-factor authentication support for GitLab	✓	✓	✓
Windows Integrated Authentication (NTLM/Kerberos) support	✓	N/A	N/A
Basic HTTP authentication support	✓	✓	✓
Proxy support	✓	✓	✓
`amd64` support	✓	✓	✓
`x86` support	✓	N/A	✗
`arm64` support	best effort	✓	best effort, no packages
`armhf` support	N/A	N/A	best effort, no packages

(*) GCM guarantees support only for the Linux distributions that are officially
supported by dotnet.

Supported Git versions

Git Credential Manager tries to be compatible with the broadest set of Git
versions (within reason). However there are some know problematic releases of
Git that are not compatible.

Git 1.x

The initial major version of Git is not supported or tested with GCM.
Git 2.26.2

This version of Git introduced a breaking change with parsing credential
configuration that GCM relies on. This issue was fixed in commit
12294990 of the Git project, and released in Git
2.27.0.

How to use

Read full command line usage here.

Configuring a proxy

See detailed information here.

Additional Resources

See the documentation index for links to additional resources.

Experimental Features

Windows broker (experimental)

Contributing

This project welcomes contributions and suggestions.
See the contributing guide to get started.

This project follows GitHub’s Open Source Code of Conduct.

License

We’re MIT licensed.
When using GitHub logos, please be sure to follow the
GitHub logo guidelines.

Источник

Git Credential Manager for Windows

NOTICE: This project is no longer being maintained. :warning:

Git Credential Manager for Windows is no longer being maintained. The cross-platform
Git Credential Manager Core (GCM Core) is the official replacement.

GCM Core is included as an optional component of Git for Windows 2.28 and will be made the default credential
helper as of Git for Windows 2.29. GCM Core can also be manually installed from this page.

NOTICE: Experiencing GitHub push/fetch problems?

GitHub will disable password-based authentication
on APIs Git Credential Manager for Windows uses to create tokens. As a result, GCM
for Windows will no longer be able to create new access tokens for GitHub.

Git Credential Manager Core (GCM Core) supports OAuth-based
authentication with GitHub and is the replacement for GCM for Windows.

Please update to Git for Windows 2.28 and select “Git Credential Manager Core” from
the installer when asked to “select a credential helper”, or manually install GCM Core
from here.

As of 22 Feb 2018, GitHub has disabled support for weak encryption which means many users will suddenly find themselves unable to authenticate using a Git for Windows which (impacts versions older than v2.16.0). DO NOT PANIC, there’s a fix. Update Git for Windows to the latest (or at least v2.16.0).

The most common error users see looks like:

fatal: HttpRequestException encountered.
   An error occurred while sending the request.
fatal: HttpRequestException encountered.
   An error occurred while sending the request.
Username for 'https://github.com':

If, after updating Git for Windows, you are still having problems authenticating with GitHub, please read this Developer Community topic which contains additional remedial actions you can take to resolve the problem.

If you are experiencing issue when using Visual Studio, please read Unable to connect to GitHub with Visual Studio.

The Git Credential Manager for Windows (GCM) provides secure Git credential storage for Windows. It’s the successor to the Windows Credential Store for Git (git-credential-winstore), which is no longer maintained. Compared to Git’s built-in credential storage for Windows (wincred), which provides single-factor authentication support working on any HTTP enabled Git repository, GCM provides multi-factor authentication support for Azure DevOps, Team Foundation Server, GitHub, and Bitbucket.

This project includes:

Secure password storage in the Windows Credential Store.
Multi-factor authentication support for Azure DevOps.
Two-factor authentication support for GitHub.
Two-factor authentication support for Bitbucket.
Personal Access Token generation and usage support for Azure DevOps, GitHub, and Bitbucket.
Non-interactive mode support for Azure DevOps backed by Azure Directory.
NTLM/Kerberos authentication for Team Foundation Server (see notes).
Optional settings for build agent optimization.

This is a community project so feel free to contribute ideas, submit bugs, fix bugs, or code new features. For detailed information on how the GCM works go to the wiki.

Download and Install

To use the GCM, you can download the latest installer. To install, double-click GCMW-{version}.exe and follow the instructions presented.

When prompted to select your terminal emulator for Git Bash you should choose the Windows’ default console window, or make sure GCM is configured to use modal dialogs. GCM cannot prompt you for credentials, at the console, in a MinTTY setup.

Manual Installation

Note for users with special installation needs, you can still extract the gcm-{version}.zip file and run install.cmd from an administrator command prompt. This allows specification of the installation options explained below.

Installation in an MSYS2 Environment

To use the GCM along with git installed with pacman in an MSYS2 environment, simply download a release zip and extract the contents directly into C:msys64usrlibgit-core (assuming your MSYS2 environment is installed in C:msys64). Then run:

git config --global credential.helper manager

How to use

You don’t. It magically works when credentials are needed. For example, when pushing to Azure DevOps, it automatically opens a window and initializes an oauth2 flow to get your token.

Build and Install from Sources

To build and install the GCM yourself, clone the sources, open the solution file in Visual Studio, and build the solution. All necessary components will be copied from the build output locations into a .Deploy folder at the root of the solution. From an elevated command prompt in the .Deploy folder issue the following command git-credential-manager install. Additional information about development and debugging are available in our documents area.

Various options are available for uniquely configured systems, like automated build systems. For systems with a non-standard placement of Git use the --path <git> parameter to supply where Git is located and thus where the GCM should be deployed to. For systems looking to avoid checking for the Microsoft .NET Framework and other similar prerequisites use the --force option. For systems looking for silent installation without any prompts, use the --passive option.

Additional Resources

Credential Manager Usage
Askpass Usage
Configuration Options
Build Agent and Automation Support
Bitbucket Specific Details
Frequently Asked Questions
Development and Debugging

Contribute

There are many ways to contribute.

Submit bugs and help us verify fixes as they are checked in.
Review code changes.
Contribute bug fixes and features.

Code Contributions

For code contributions, you will need to complete a Contributor License Agreement (CLA). Briefly, this agreement testifies that you grant us permission to use the submitted change according to the terms of the project’s license, and that the work being submitted is under the appropriate copyright.

Please submit a Contributor License Agreement (CLA) before submitting a pull request. You may visit https://cla.microsoft.com to sign digitally. Alternatively, download the agreement Microsoft Contribution License Agreement.pdf, sign, scan, and email it back to cla@microsoft.com. Be sure to include your GitHub user name along with the agreement. Once we have received the signed CLA, we’ll review the request.

Code of Conduct

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

License

This project uses the MIT License.

Источник

Аутентификация – это сложно. Сложно отлаживать, сложно тестировать, сложно получать доступ.

Эти слова были правдой как в июле 2020 года, так и сегодня. Цель Git Credential Manager (GCM) – сделать аутентификацию к удаленному репозиторию Git легкой и безопасной, вне зависимости от того, где хранится код или как вы предпочитаете работать. Коротко: GCM хочет стать универсальной аутентификацией Git.

В предыдущей статье писалось о риске распространения универсальных стандартов и о том, что внедрение Git Credential Manager Core (GCM Core) будет означать появление еще одного помощника в работе с мандатами. Удалось заменить GCM для Windows, Mac и Linux на новый GCM! Исходный код старых проектов заархивирован и больше не поставляется с такими дистрибутивами как Git для Windows.

Поэтому моникер Core был убран из названия проекта, чтобы стать Git Credential Manager или сокращенно GCM.

GCM

У GCM появился новый дом на GitHub https://github.com/GitCredentialManager.

Размещение на github.com/microsoft или github.com/github не совсем соответствовало этике GCM как открытого, универсального и агностического проекта. Текущие проблемы и запросы на исправление были перенесены, и по-прежнему приветствуются желающие внести вклад в проект.

Страница GCM в GitHub

Взаимодействие с удаленными HTTP-серверами без помощника по учетным данным, такого как GCM, усложняется с удалением аутентификации по логину/паролю в GitHub и BitBucket. GCM упрощает эту задачу, а благодаря разработкам, таким как GitHub Mobile для двухфакторной аутентификации и поддержка потока кода устройства OAuth, аутентификация становится лучше.

Привет Linux!

GCM❤Linux

В стремлении получить универсальное решение для аутентификации в Git, выполнена работа над тем, чтобы GCM одинаково работал на различных дистрибутивах Linux с упором на дистрибутивы на базе Debian.

Доступны пакеты Debian, которые можно загрузить со страницы выпусков GitHub, а также tar-архивы для других дистрибутивов (только для x64 версии Intel). Построение на платформе .NET облегчает сборку и запуск везде, где работает среда выполнения .NET. Со временем планируется расширить матрицу поддержки дистрибутивов и процессорных архитектур (например, добавить поддержку ARM64).

В связи с широкой и многообразной природой дистрибутивов Linux важно, что GCM предлагает много вариантов хранения учетных данных. В дополнение к зашифрованным GPG файлам добавлена поддержка Secret Service API через libsecret (также см. GNOME Keyring), которая дает опыт схожий с тем, что предоставляется в GCM на Windows и macOS.

Подсистема Windows для Linux

В дополнение к дистрибутивам Linux также реализована специальная поддержка GCM для подсистемы Windows для Linux (WSL). Использование GCM с WSL означает, что все ваши установленные WSL могут совместно использовать учетные данные Git друг с другом и с хостом Windows, что разрешает вам легко смешивать и сочетать среды разработки.

GCM для WSL

Смотрите больше о GCM для WSL здесь.

Привет, GitLab

Универсальность означает не только работу с большим количеством мест, но и любую службу хостинга Git. Благодаря активному сообществу, GCM постоянно становится лучше. И теперь GCM поддерживает GitLab.

GCM и Git хостинг

Никаких терминалов!

Несмотря на любовь к терминалу, не всем удобно вводить команды и отвечать на подсказки с помощью клавиатуры. Кроме того, многие инструменты и IDE, предлагающие интеграцию с Git, делают это путем передачи исполняемого файла git, что означает, что GCM может быть вызван для аутентификации из GUI-приложения, где нет терминала.

GCM предлагает полноценные графические подсказки аутентификации в Windows, благодаря проекту Avalonia, предоставляющего кросс-платформенный .NET XAML фреймворк. Также предоставляются графические подсказки на macOS и Linux.

GCM интерфейс на разных платформах

GCM продолжает поддерживать подсказки в терминале в качестве опции по умолчанию для подсказок. Известны среды, где нет графического интерфейса (например, при подключении по SSH без переадресации дисплея), и вместо этого представляются эквивалентные текстовые подсказки. При желании можно вручную отключить подсказки GUI.

Обеспечение безопасности цепочки поставок программного обеспечения

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

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

Храните ВСЕ учетные записи

Git Credential Manager создает и хранит учетные данные для доступа к репозиториям Git на множестве платформ. Учетные данные хранятся с помощью стандартных промышленных API шифрования и хранения.

GCM использует менеджер учетных данных Windows и связку ключей для входа в систему в macOS.

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

GCM для всех платформ

Также GCM теперь может использовать помощник Git git-credential-cache, который собирается и доступен во многих дистрибутивах Git. Этот вариант подходит для облачных оболочек или эфемерных сред, когда нет желания постоянно сохранять учетные данные на диске, но при этом избежать запроса при каждом git fetch или git push.

Современная проверка подлинности Windows (экспериментальная)

Еще один способ обеспечения безопасности учетных данных – поддержка на аппаратном уровне с помощью таких технологий, как Trusted Platform Module (TPM) или Secure Enclave. Кроме того, предприятия, желающие убедится в том, что устройство или учетные данные не скомпрометированы, могут использовать политики условного доступа.

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

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

GCM и брокеры аутентификации

GCM получил экспериментальную поддержку брокерской аутентификации (пока только для Windows)!

В Windows брокер проверки подлинности – компонент, который впервые появился в Windows 10 и известен как Web Account Manager (WAM). WAM разрешает таким приложениям, как GCM поддерживать современные способы аутентификации, такие как, Windows Hello и применять политики условного доступа, установленные на работе или учебе.

Обратите внимание, что поддержка брокера Windows пока экспериментальна и ограничивается проверкой подлинности рабочих и учебных учетных записей Microsoft в Azure DevOps.

Больше о GCM и WAM рассказывается по этой ссылке, в том числе о том, как зарегистрироваться и о текущих известных проблемах.

Что такое условный доступ?

Условный доступ – это идея предоставления доступа к системе или ресурсу только при соблюдении критериев. Эти критерии могут включать такие вещи, как: проверка актуальности и работоспособности антивирусного программного обеспечения на устройстве, безопасное соединение через VPN, использование 2FA или динамическое обнаружение подозрительной активности из учетной записи пользователя.

Условный доступ

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

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

Еще больше улучшений

За последние 18 месяцев в GCM появилось много функций и улучшений. Вот краткое изложение дополнительных обновлений после публикации в июле 2020 года:

Автоматическое определение локальных/самостоятельно размещенных экземпляров.
Поддержка GitHub Enterprise Server и GitHub AE.
Общие кэши токенов Microsoft Identity с другими инструментами разработчика.
Улучшенная поддержка сетевых прокси.
Поддержка пользовательских корневых сертификатов TLS/SSL.
Установщик Windows без администратора.
Улучшенная обработка и вывод командной строки.
Поддержка корпоративных настроек по умолчанию в Windows.
Многопользовательская поддержка.
Улучшенная диагностика.

Планы на будущее

Несмотря на значительный прогресс в достижении цели универсального опыта, снижение темпа в ближайшее время не планируется и GCM будет развиваться.

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

***

Материалы по теме

Git за полчаса: руководство для начинающих
Основы Git: контроль версий для самых маленьких
10 полезных Git команд, которые облегчат работу
GitLab или GitHub? Как выбрать ресурс под определённый тип репозитория

Источник

Хранилище учётных данных

Если для подключения к удалённым серверам вы используете протокол 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 <path>, который определяет где будет хранится файл с открытыми учётными данный (по умолчанию используется ~/.git-credentials).
Помощник «cache» принимает опцию --timeout <seconds>, которая изменяет промежуток времени, в течение которого демон остаётся запущенным (по умолчанию «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

Это команда, которая начинает взаимодействие.
После этого Git-credential ожидает данные из стандартного потока ввода.
Мы передаём ему то, что знаем: протокол и имя сервера.
Пустая строка обозначает, что ввод закончен и система управления учётными данными должна ответить, что ей известно.
После этого Git-credential выполняет какую-то работу и выводит обнаруженную информацию.
Если учётные данные не найдены, 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] <action>.
Протокол ввода/вывода такой же как и у 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

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

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

https://bob:s3cre7@mygithost

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

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

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

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

Мы снова напишем расширение на 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] <action>'
    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=#{prot}"
        puts "host=#{host}"
        puts "username=#{user}"
        puts "password=#{pass}"
        exit(0)
    end
end

Здесь мы разбираем аргументы командной строки, позволяя указывать пользователям входной файл. По умолчанию это ~/.git-credentials.
Эта программа отвечает только если операцией является get и файл хранилища существует.
В цикле считываются данные из стандартного ввода, до тех пор пока не будет прочитана пустая строка.
Введённые данные для дальнейшего использования сохраняются в отображении known.
Этот цикл читает содержимое файла хранилища, выполняя поиск соответствия.
Если протокол и сервер из 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'

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

Источник

Universal Git Authentication

“Authentication is hard. Hard to debug, hard to test, hard to get right.” – Me

These words were true when I wrote them back in July 2020, and they’re still true today. The goal of Git Credential Manager (GCM) is to make the task of authenticating to your remote Git repositories easy and secure, no matter where your code is stored or how you choose to work. In short, GCM wants to be Git’s universal authentication experience.

In my last blog post, I talked about the risk of proliferating “universal standards” and how introducing Git Credential Manager Core (GCM Core) would mean yet another credential helper in the wild. I’m therefore pleased to say that we’ve managed to successfully replace both GCM for Windows and GCM for Mac and Linux with the new GCM! The source code of the older projects has been archived, and they are no longer shipped with distributions like Git for Windows!

In order to celebrate and reflect this successful unification, we decided to drop the “Core” moniker from the project’s name to become simply Git Credential Manager or GCM for short.

If you have followed the development of GCM closely, you might have also noticed we have a new home on GitHub in our own organization, github.com/GitCredentialManager!

We felt being homed under github.com/microsoft or github.com/github didn’t quite represent the ethos of GCM as an open, universal and agnostic project. All existing issues and pull requests were migrated, and we continue to welcome everyone to contribute to the project.

Interacting with HTTP remotes without the help of a credential helper like GCM is becoming more difficult with the removal of username/password authentication at GitHub and Bitbucket. Using GCM makes it easy, and with exciting developments such as using GitHub Mobile for two-factor authentication and OAuth device code flow support, we are making authentication more seamless.

Hello, Linux!

In the quest to become a universal solution for Git authentication, we’ve worked hard on getting GCM to work well on various Linux distributions, with a primary focus on Debian-based distributions.

Today we have Debian packages available to download from our GitHub releases page, as well as tarballs for other distributions (64-bit Intel only). Being built on the .NET platform means there should be a reduced effort to build and run anywhere the .NET runtime runs. Over time, we hope to expand our support matrix of distributions and CPU architectures (by adding ARM64 support, for example).

Due to the broad and varied nature of Linux distributions, it’s important that GCM offers many different credential storage options. In addition to GPG encrypted files, we added support for the Secret Service API via libsecret (also see the GNOME Keyring), which provides a similar experience to what we provide today in GCM on Windows and macOS.

Windows Subsystem for Linux

In addition to Linux distributions, we also have special support for using GCM with Windows Subsystem for Linux (WSL). Using GCM with WSL means that all your WSL installations can share Git credentials with each other and the Windows host, enabling you to easily mix and match your development environments.

You can read more about using GCM inside of your WSL installations here.

Hello, GitLab

Being universal doesn’t just mean we want to run in more places, but also that we can help more users with whatever Git hosting service they choose to use. We are very lucky to have such an engaged community that is constantly working to make GCM better for everyone.

On that note, I am thrilled to share that through a community contribution, GCM now has support for GitLab. Welcome to the family!

Look Ma, no terminals!

We love the terminal and so does GCM. However, we know that not everyone feels comfortable typing in commands and responding to prompts via the keyboard. Also, many popular tools and IDEs that offer Git integration do so by shelling out to the git executable, which means GCM may be called upon to perform authentication from a GUI app where there is no terminal(!)

GCM has always offered full graphical authentication prompts on Windows, but thanks to our adoption of the Avalonia project that provides a cross-platform .NET XAML framework, we can now present graphical prompts on macOS and Linux.

GCM continues to support terminal prompts as a first-class option for all prompts. We detect environments where there is no GUI (such as when connected over SSH without display forwarding) and instead present the equivalent text-based prompts. You can also manually disable the GUI prompts if you wish.

Securing the software supply chain

Keeping your source code secure is a critical step in maintaining trust in software, whether that be keeping commercially sensitive source code away from prying eyes or protecting against malicious actors making changes in both closed and open source projects that underpin much of the modern world.

In 2020, an extensive cyberattack was exposed that impacted parts of the US federal government as well as several major software companies. The US president’s recent executive order in response to this cyberattack brings into focus the importance of mechanisms such as multi-factor authentication, conditional access policies, and generally securing the software supply chain.

Store ALL the credentials

Git Credential Manager creates and stores credentials to access Git repositories on a host of platforms. We hold in the highest regard the need to keep your credentials and access secure. That’s why we always keep your credentials stored using industry standard encryption and storage APIs.

GCM makes use of the Windows Credential Manager on Windows and the login keychain on macOS.

In addition to these existing mechanisms, we also support several alternatives across supported platforms, giving you the choice of how and where you wish to store your generated credentials (such as GPG-encrypted credential files).

GCM can now also use Git’s git-credential-cache helper that is commonly built and available in many Git distributions. This is a great option for cloud shells or ephemeral environments when you don’t want to persist credentials permanently to disk but still want to avoid a prompt for every git fetch or git push.

Modern windows authentication (experimental)

Another way to keep your credentials safe at rest is with hardware-level support through technologies like the Trusted Platform Module (TPM) or Secure Enclave. Additionally, enterprises wishing to make sure your device or credentials have not been compromised may want to enforce conditional access policies.

Integrating with these kinds of security modules or enforcing policies can be tricky and is platform-dependent. It’s often easier for applications to hand over responsibility for the credential acquisition, storage, and policy
enforcement to an authentication broker.

An authentication broker performs credential negotiation on behalf of an app, simplifying many of these problems, and often comes with the added benefit of deeper integration with operating system features such as biometrics.

I’m happy to announce that GCM has gained experimental support for brokered authentication (Windows-only at the moment)!

On Windows, the authentication broker is a component that was first introduced in Windows 10 and is known as the Web Account Manager (WAM). WAM enables apps like GCM to support modern authentication experiences such as Windows Hello and will apply conditional access policies set by your work or school.

Please note that support for the Windows broker is currently experimental and limited to authentication of Microsoft work and school accounts against Azure DevOps.

Click here to read more about GCM and WAM, including how to opt-in and current known issues.

Even more improvements

GCM has been a hive of activity in the past 18 months, with too many new features and improvements to talk about in detail! Here’s a quick rundown of additional updates since our July 2020 post:

Automatic on-premises/self-hosted instance detection
GitHub Enterprise Server and GitHub AE support
Shared Microsoft Identity token caches with other developer tools
Improved network proxy support
Custom TLS/SSL root certificate support
Admin-less Windows installer
Improved command line handling and output
Enterprise default setting support on Windows
Multi-user support
Better diagnostics

Thank you!

The GCM team would also like to personally thank all the people who have made contributions, both large and small, to the project:

@vtbassmatt, @kyle-rader, @mminns, @ldennington, @hickford, @vdye, @AlexanderLanin, @derrickstolee, @NN, @johnemau, @karlhorky, @garvit-joshi, @jeschu1, @WormJim, @nimatt, @parasychic, @cjsimon, @czipperz, @jamill, @jessehouwing, @shegox, @dscho, @dmodena, @geirivarjerstad, @jrbriggs, @Molkree, @4brunu, @julescubtree, @kzu, @sivaraam, @mastercoms, @nightowlengineer

Future work

While we’ve made a great deal of progress toward our universal experience goal, we’re not slowing down anytime soon; we’re still full steam ahead with GCM!

Our focus for the next period will be on iterating and improving our authentication broker support, providing stronger protection of credentials, and looking to increase performance and compatibility with more environments and uses.

Explore more from GitHub

Engineering

Posts straight from the GitHub engineering team.

Learn more

The ReadME Project

Stories and voices from the developer community.

Learn more

GitHub Actions

Native CI/CD alongside code hosted in GitHub.

Learn more

Work at GitHub!

Check out our current job openings.

Learn more

Источник

GitLab

- GitLab: the DevOps platform
- Explore GitLab
- Install GitLab
- How GitLab compares
- Get started
- GitLab docs
- GitLab Learn
Pricing
Talk to an expert

Help
- Help
- Support
- Community forum
- Submit feedback
- Contribute to GitLab
- Switch to GitLab Next
Projects
Groups
Snippets
Sign up now
Login
Sign in / Register

git-credential-manager

Project ID: 40701805

Star
0

Secure, cross-platform Git credential storage with authentication to GitHub, Azure Repos, and other popular Git hosting services.

Find file

Download source code

zip
tar.gz
tar.bz2
tar

Clone

Clone with SSH
Clone with HTTPS
Open in your IDE

Visual Studio Code (SSH)

Visual Studio Code (HTTPS)

IntelliJ IDEA (SSH)

IntelliJ IDEA (HTTPS)

Copy SSH clone URLgit@gitlab.com:truestorybaby/git-credential-manager.git
Copy HTTPS clone URLhttps://gitlab.com/truestorybaby/git-credential-manager.git

README
LICENSE
CONTRIBUTING

Источник

Git Credential Manager

Git Credential Manager (GCM) is a secure Git credential helper built on .NET that runs on Windows, macOS, and Linux.

Compared to Git’s built-in credential helpers (Windows: wincred, macOS: osxkeychain, Linux: gnome-keyring/libsecret) which provides single-factor authentication support working on any HTTP-enabled Git repository, GCM provides multi-factor authentication support for Azure DevOps, Azure DevOps Server (formerly Team Foundation Server), GitHub, Bitbucket, and GitLab.

Git Credential Manager (GCM) replaces the .NET Framework-based Git Credential Manager for Windows (GCM), and the Java-based Git Credential Manager for Mac and Linux (Java GCM), providing a consistent authentication experience across all platforms.

Current status

Git Credential Manager is currently available for Windows, macOS, and Linux*. GCM only works with HTTP(S) remotes; you can still use Git with SSH:

Azure DevOps SSH
GitHub SSH
Bitbucket SSH

Feature	Windows	macOS	Linux
Installer/uninstaller	✓	✓	✓
Secure platform credential storage	✓ (see more)	✓ (see more)	✓ (see more)
Multi-factor authentication support for Azure DevOps	✓	✓	✓
Two-factor authentication support for GitHub	✓	✓	✓
Two-factor authentication support for Bitbucket	✓	✓	✓
Two-factor authentication support for GitLab	✓	✓	✓
Windows Integrated Authentication (NTLM/Kerberos) support	✓	N/A	N/A
Basic HTTP authentication support	✓	✓	✓
Proxy support	✓	✓	✓
`amd64` support	✓	✓	✓
`x86` support	✓	N/A	✗
`arm64` support	best effort	via Rosetta 2	best effort, no packages
`armhf` support	N/A	N/A	best effort, no packages

(*) GCM guarantees support for the below Linux distributions. GCM maintainers also monitor and evaluate issues opened against other distributions to determine community interest/engagement and whether an emerging platform should become fully-supported.

Debian/Ubuntu/Linux Mint
Fedora/CentOS/RHEL
Alpine

Download and Install

macOS Homebrew

The preferred installation mechanism is using Homebrew; we offer a Cask in our custom Tap.

To install, run the following:

brew tap microsoft/git
brew install --cask git-credential-manager-core

After installing you can stay up-to-date with new releases by running:

brew upgrade git-credential-manager-core

Git Credential Manager for Mac and Linux (Java-based GCM)

If you have an existing installation of the ‘Java GCM’ on macOS and you have installed this using Homebrew, this installation will be unlinked (brew unlink git-credential-manager) when GCM is installed.

Uninstall

To uninstall, run the following:

brew uninstall --cask git-credential-manager-core

macOS Package

We also provide a .pkg installer with each release. To install, double-click the installation package and follow the instructions presented.

Uninstall

To uninstall, run the following:

sudo /usr/local/share/gcm-core/uninstall.sh

Linux

Experimental: install from source helper script

If you would like to help dogfood our new install from source helper script,
run the following:

To ensure curl is installed:

If curl is not installed, please use your distribution’s package manager
to install it.

To download and run the script:

curl -LO https://raw.githubusercontent.com/GitCredentialManager/git-credential-manager/main/src/linux/Packaging.Linux/install-from-source.sh &&
sh ./install-from-source.sh &&
git-credential-manager-core configure

Note: You will be prompted to enter your credentials so that the script
can download GCM’s dependencies using your distribution’s package
manager.

Ubuntu/Debian distributions

Download the latest .deb package, and run the following:

sudo dpkg -i <path-to-package>
git-credential-manager-core configure

Note: Although packages were previously offered on certain
Microsoft Ubuntu package feeds,
GCM no longer publishes to these repositories. Please install the
Debian package using the above instructions instead.

To uninstall:

git-credential-manager-core unconfigure
sudo dpkg -r gcmcore

Other distributions

Download the latest tarball, and run the following:

tar -xvf <path-to-tarball> -C /usr/local/bin
git-credential-manager-core configure

To uninstall:

git-credential-manager-core unconfigure
rm $(command -v git-credential-manager-core)

Note: all Linux distributions require additional configuration to use GCM.

Windows

GCM is included with Git for Windows, and the latest version is included in each new Git for Windows release. This is the preferred way to install GCM on Windows. During installation you will be asked to select a credential helper, with GCM being set as the default.

Standalone installation

You can also download the latest installer for Windows to install GCM standalone.

⚠️ Important ⚠️

Installing GCM as a standalone package on Windows will forcibly override the version of GCM that is bundled with Git for Windows, even if the version bundled with Git for Windows is a later version.

There are two flavors of standalone installation on Windows:

User (preferred) (gcmcoreuser-win*):

Does not require administrator rights. Will install only for the current user and updates only the current user’s Git configuration.
System (gcmcore-win*):

Requires administrator rights. Will install for all users on the system and update the system-wide Git configuration.

To install, double-click the desired installation package and follow the instructions presented.

Uninstall (Windows 10)

To uninstall, open the Settings app and navigate to the Apps section. Select «Git Credential Manager» and click «Uninstall».

Uninstall (Windows 7-8.1)

To uninstall, open Control Panel and navigate to the Programs and Features screen. Select «Git Credential Manager» and click «Remove».

Windows Subsystem for Linux (WSL)

Git Credential Manager can be used with the Windows Subsystem for Linux
(WSL) to enable secure authentication of your remote Git
repositories from inside of WSL.

Please see the GCM on WSL docs for more information.

Supported Git versions

Git Credential Manager tries to be compatible with the broadest set of Git
versions (within reason). However there are some know problematic releases of
Git that are not compatible.

Git 1.x

The initial major version of Git is not supported or tested with GCM.
Git 2.26.2

This version of Git introduced a breaking change with parsing credential
configuration that GCM relies on. This issue was fixed in commit 12294990
of the Git project, and released in Git 2.27.0.

How to use

Once it’s installed and configured, Git Credential Manager is called implicitly by Git.
You don’t have to do anything special, and GCM isn’t intended to be called directly by the user.
For example, when pushing (git push) to Azure DevOps, Bitbucket, or GitHub, a window will automatically open and walk you through the sign-in process.
(This process will look slightly different for each Git host, and even in some cases, whether you’ve connected to an on-premises or cloud-hosted Git host.)
Later Git commands in the same repository will re-use existing credentials or tokens that GCM has stored for as long as they’re valid.

Read full command line usage here.

Configuring a proxy

See detailed information here.

Additional Resources

Frequently asked questions
Development and debugging
Command-line usage
Configuration options
Environment variables
Enterprise configuration
Network and HTTP configuration
Credential stores
Architectural overview
Host provider specification
Azure Repos OAuth tokens
GitLab support

Experimental Features

Windows broker (experimental)

Contributing

This project welcomes contributions and suggestions.
See the contributing guide to get started.

This project follows GitHub’s Open Source Code of Conduct.

License

We’re MIT licensed.
When using GitHub logos, please be sure to follow the GitHub logo guidelines.

Источник

Git Credential Manager

Git Credential Manager (GCM) is a secure Git credential helper built on .NET that runs on Windows, macOS, and Linux.

Current status

Git Credential Manager is currently available for Windows, macOS, and Linux*. GCM only works with HTTP(S) remotes; you can still use Git with SSH:

Azure DevOps SSH
GitHub SSH
Bitbucket SSH

Feature	Windows	macOS	Linux
Installer/uninstaller	✓	✓	✓
Secure platform credential storage	✓ (see more)	✓ (see more)	✓ (see more)
Multi-factor authentication support for Azure DevOps	✓	✓	✓
Two-factor authentication support for GitHub	✓	✓	✓
Two-factor authentication support for Bitbucket	✓	✓	✓
Two-factor authentication support for GitLab	✓	✓	✓
Windows Integrated Authentication (NTLM/Kerberos) support	✓	N/A	N/A
Basic HTTP authentication support	✓	✓	✓
Proxy support	✓	✓	✓
`amd64` support	✓	✓	✓
`x86` support	✓	N/A	✗
`arm64` support	best effort	via Rosetta 2	best effort, no packages
`armhf` support	N/A	N/A	best effort, no packages

Debian/Ubuntu/Linux Mint
Fedora/CentOS/RHEL
Alpine

Download and Install

macOS Homebrew

The preferred installation mechanism is using Homebrew; we offer a Cask in our custom Tap.

To install, run the following:

brew tap microsoft/git
brew install --cask git-credential-manager-core

After installing you can stay up-to-date with new releases by running:

brew upgrade git-credential-manager-core

Git Credential Manager for Mac and Linux (Java-based GCM)

Uninstall

To uninstall, run the following:

brew uninstall --cask git-credential-manager-core

macOS Package

We also provide a .pkg installer with each release. To install, double-click the installation package and follow the instructions presented.

Uninstall

To uninstall, run the following:

sudo /usr/local/share/gcm-core/uninstall.sh

Linux

Experimental: install from source helper script

If you would like to help dogfood our new install from source helper script,
run the following:

To ensure curl is installed:

If curl is not installed, please use your distribution’s package manager
to install it.

To download and run the script:

curl -LO https://raw.githubusercontent.com/GitCredentialManager/git-credential-manager/main/src/linux/Packaging.Linux/install-from-source.sh &&
sh ./install-from-source.sh &&
git-credential-manager-core configure

Note: You will be prompted to enter your credentials so that the script
can download GCM’s dependencies using your distribution’s package
manager.

Ubuntu/Debian distributions

Download the latest .deb package, and run the following:

sudo dpkg -i <path-to-package>
git-credential-manager-core configure

To uninstall:

git-credential-manager-core unconfigure
sudo dpkg -r gcmcore

Other distributions

Download the latest tarball, and run the following:

tar -xvf <path-to-tarball> -C /usr/local/bin
git-credential-manager-core configure

To uninstall:

git-credential-manager-core unconfigure
rm $(command -v git-credential-manager-core)

Note: all Linux distributions require additional configuration to use GCM.

Windows

Standalone installation

You can also download the latest installer for Windows to install GCM standalone.

⚠️ Important ⚠️

There are two flavors of standalone installation on Windows:

User (preferred) (gcmcoreuser-win*):

Does not require administrator rights. Will install only for the current user and updates only the current user’s Git configuration.
System (gcmcore-win*):

Requires administrator rights. Will install for all users on the system and update the system-wide Git configuration.

To install, double-click the desired installation package and follow the instructions presented.

Uninstall (Windows 10)

To uninstall, open the Settings app and navigate to the Apps section. Select «Git Credential Manager» and click «Uninstall».

Uninstall (Windows 7-8.1)

To uninstall, open Control Panel and navigate to the Programs and Features screen. Select «Git Credential Manager» and click «Remove».

Windows Subsystem for Linux (WSL)

Git Credential Manager can be used with the Windows Subsystem for Linux
(WSL) to enable secure authentication of your remote Git
repositories from inside of WSL.

Please see the GCM on WSL docs for more information.

Supported Git versions

Git Credential Manager tries to be compatible with the broadest set of Git
versions (within reason). However there are some know problematic releases of
Git that are not compatible.

Git 1.x

The initial major version of Git is not supported or tested with GCM.
Git 2.26.2

This version of Git introduced a breaking change with parsing credential
configuration that GCM relies on. This issue was fixed in commit 12294990
of the Git project, and released in Git 2.27.0.

How to use

Once it’s installed and configured, Git Credential Manager is called implicitly by Git.
You don’t have to do anything special, and GCM isn’t intended to be called directly by the user.
For example, when pushing (git push) to Azure DevOps, Bitbucket, or GitHub, a window will automatically open and walk you through the sign-in process.
(This process will look slightly different for each Git host, and even in some cases, whether you’ve connected to an on-premises or cloud-hosted Git host.)
Later Git commands in the same repository will re-use existing credentials or tokens that GCM has stored for as long as they’re valid.

Read full command line usage here.

Configuring a proxy

See detailed information here.

Additional Resources

Frequently asked questions
Development and debugging
Command-line usage
Configuration options
Environment variables
Enterprise configuration
Network and HTTP configuration
Credential stores
Architectural overview
Host provider specification
Azure Repos OAuth tokens
GitLab support

Experimental Features

Windows broker (experimental)

Contributing

This project welcomes contributions and suggestions.
See the contributing guide to get started.

This project follows GitHub’s Open Source Code of Conduct.

License

We’re MIT licensed.
When using GitHub logos, please be sure to follow the GitHub logo guidelines.

Источник