Git-Credential-Manager-for-Windows
Secure Git credential storage for Windows with support for Visual Studio Team Services, GitHub, and Bitbucket multi-factor authentication.
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:
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.
Community
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-
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-
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:\msys64\usr\lib\git-core (assuming your MSYS2 environment is installed in C:\msys64 ). Then run:
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 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
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.
This project is maintained by microsoft
Hosted on GitHub Pages — Theme by orderedlist
Как отключить Git Credential Manager для Windows?
Я заметил, что в последней версии Git по умолчанию теперь появляется диалоговое окно «Git Credential Manager для Windows» вместо того, чтобы каждый раз запрашивать у меня пароль в приглашении Bash.
Я действительно ненавижу это поведение. Как я могу просто отключить его и вернуться к вводу пароля в оболочке Bash каждый раз?
Кстати, я не хочу, чтобы Git кэшировал мои учетные данные каким-либо образом, будь то учетные данные Windows или какой-либо внутренний демон. Я хочу отключить все кэширование учетных данных.
Хорошо, я обнаружил, что вам нужно либо не устанавливать флажок «Git Credential Manager» во время установки Git для Windows, либо (после установки) запустить оболочку Bash от имени администратора и использовать git config —edit —system для удаления helper = manager строка helper = manager чтобы он больше не регистрировался как помощник по учетным данным.
Для получения бонусных баллов используйте git config —edit —global и вставьте:
Отключить всплывающее окно с учетными данными OpenSSH тоже.
Мне удалось удалить Git Credential Manager для Windows с помощью опции удаления:
Запустите эту команду в C:\Program Files\Git\mingw64\libexec\git-core
Еще один вариант, который мне пришлось использовать с VSTS:
git config credential.modalprompt false —global
Это не сработало для меня:
Но с флагом —force это сработало:
Я мог видеть этот след после того, как бегу:
Также я добавил имя пользователя Git:
В конце я поставил эту команду:
Я проверяю, работает ли агент SSH — откройте окно Bash для запуска этой команды
Затем в папке users/yourName компьютера, где находится .ssh, добавьте соединение (все еще в Bash):
Я проверил все настройки, которые я добавил выше:
И когда я сделал git push снова, мне пришлось добавить имя пользователя и пароль только в первый раз.
С тех пор, используя git push , у меня больше нет сообщения для ввода учетных данных Git.
После этих настроек я тоже получил письмо с сообщением:
- Win + R , введите «compmgmt.msc»,
- выберите «Услуги и приложения» → «Услуги»
- найти там диспетчер учетных данных,
- измените Тип запуска на Отключено, остановите его, Apply и OK .
У меня была эта проблема, и я только удалил файл git-credential-manager.exe из:
Я хотел использовать диспетчер учетных данных для обычного использования, но у меня есть сценарии, в которых я явно не хочу никаких git.exe от git.exe . Вот как я вызываю Git из моих скриптов:
Таким образом, скрипт всегда видит «правильную» настройку без приглашения без необходимости настройки.
(Git для Windows 2.13.3)
Я нашел вариант, который также может пригодиться:
Но обратите внимание, что git.exe -c credential.interactive=never . не работает (кажется, что -c не перенаправляется в Git Credential Manager для Windows или чего-либо еще).
Таким образом, вы можете использовать GCMfW, но он никогда не подскажет вам; он просто ищет учетные данные, которые могут быть очень полезны в неинтерактивных средах.
Git за полчаса: руководство для начинающих
В последние годы популярность git демонстрирует взрывной рост. Эта система контроля версий используется различными проектами с открытым исходным кодом.
Новичков часто пугает большое количество замысловатых команд и сложных аргументов. Но для начала все они и не нужны. Можно начать с изучения наиболее часто используемых команд, и после этого постепенно расширять свои знания. Именно так мы и поступим в этой статье. Поехали!
Основы
Git — это набор консольных утилит, которые отслеживают и фиксируют изменения в файлах (чаще всего речь идет об исходном коде программ, но вы можете использовать его для любых файлов на ваш вкус). С его помощью вы можете откатиться на более старую версию вашего проекта, сравнивать, анализировать, сливать изменения и многое другое. Этот процесс называется контролем версий. Существуют различные системы для контроля версий. Вы, возможно, о них слышали: SVN, Mercurial, Perforce, CVS, Bitkeeper и другие.
Git является распределенным, то есть не зависит от одного центрального сервера, на котором хранятся файлы. Вместо этого он работает полностью локально, сохраняя данные в папках на жестком диске, которые называются репозиторием. Тем не менее, вы можете хранить копию репозитория онлайн, это сильно облегчает работу над одним проектом для нескольких людей. Для этого используются сайты вроде github и bitbucket.
Установка
Установить git на свою машину очень просто:
- Linux — нужно просто открыть терминал и установить приложение при помощи пакетного менеджера вашего дистрибутива. Для Ubuntu команда будет выглядеть следующим образом:
sudo apt-get install git
- Windows — мы рекомендуем git for windows, так как он содержит и клиент с графическим интерфейсом, и эмулятор bash.
- OS X — проще всего воспользоваться homebrew. После его установки запустите в терминале:
Если вы новичок, клиент с графическим интерфейсом(например GitHub Desktop и Sourcetree) будет полезен, но, тем не менее, знать команды очень важно.
Настройка
Итак, мы установили git, теперь нужно добавить немного настроек. Есть довольно много опций, с которыми можно играть, но мы настроим самые важные: наше имя пользователя и адрес электронной почты. Откройте терминал и запустите команды:
git config —global user.name «My Name»
git config —global user.email myEmail@example.com
Теперь каждое наше действие будет отмечено именем и почтой. Таким образом, пользователи всегда будут в курсе, кто отвечает за какие изменения — это вносит порядок.
Создание нового репозитория
Как мы отметили ранее, git хранит свои файлы и историю прямо в папке проекта. Чтобы создать новый репозиторий, нам нужно открыть терминал, зайти в папку нашего проекта и выполнить команду init. Это включит приложение в этой конкретной папке и создаст скрытую директорию .git, где будет храниться история репозитория и настройки.
Создайте на рабочем столе папку под названием git_exercise. Для этого в окне терминала введите:
$ mkdir Desktop/git_exercise/
$ cd Desktop/git_exercise/
$ git init
Командная строка должна вернуть что-то вроде:
Initialized empty Git repository in /home/user/Desktop/git_exercise/.git/
Это значит, что наш репозиторий был успешно создан, но пока что пуст. Теперь создайте текстовый файл под названием hello.txt и сохраните его в директории git_exercise.
Определение состояния
status — это еще одна важнейшая команда, которая показывает информацию о текущем состоянии репозитория: актуальна ли информация на нём, нет ли чего-то нового, что поменялось, и так далее. Запуск git status на нашем свежесозданном репозитории должен выдать:
$ git status
On branch master
Initial commit
Untracked files:
(use «git add . » to include in what will be committed)
hello.txt
Сообщение говорит о том, что файл hello.txt неотслеживаемый. Это значит, что файл новый и система еще не знает, нужно ли следить за изменениями в файле или его можно просто игнорировать. Для того, чтобы начать отслеживать новый файл, нужно его специальным образом объявить.
Подготовка файлов
В git есть концепция области подготовленных файлов. Можно представить ее как холст, на который наносят изменения, которые нужны в коммите. Сперва он пустой, но затем мы добавляем на него файлы (или части файлов, или даже одиночные строчки) командой add и, наконец, коммитим все нужное в репозиторий (создаем слепок нужного нам состояния) командой commit.
В нашем случае у нас только один файл, так что добавим его:
Если нам нужно добавить все, что находится в директории, мы можем использовать
Проверим статус снова, на этот раз мы должны получить другой ответ:
$ git status
On branch master
Initial commit
Changes to be committed:
(use «git rm —cached . » to unstage)
new file: hello.txt
Файл готов к коммиту. Сообщение о состоянии также говорит нам о том, какие изменения относительно файла были проведены в области подготовки — в данном случае это новый файл, но файлы могут быть модифицированы или удалены.
Коммит(фиксация изменений)
Коммит представляет собой состояние репозитория в определенный момент времени. Это похоже на снапшот, к которому мы можем вернуться и увидеть состояние объектов на определенный момент времени.
Чтобы зафиксировать изменения, нам нужно хотя бы одно изменение в области подготовки (мы только что создали его при помощи git add), после которого мы может коммитить:
$ git commit -m «Initial commit.»
Эта команда создаст новый коммит со всеми изменениями из области подготовки (добавление файла hello.txt). Ключ -m и сообщение «Initial commit.» — это созданное пользователем описание всех изменений, включенных в коммит. Считается хорошей практикой делать коммиты часто и всегда писать содержательные комментарии.
Удаленные репозитории
Сейчас наш коммит является локальным — существует только в директории .git на нашей файловой системе. Несмотря на то, что сам по себе локальный репозиторий полезен, в большинстве случаев мы хотим поделиться нашей работой или доставить код на сервер, где он будет выполняться.
1. Подключение к удаленному репозиторию
Чтобы загрузить что-нибудь в удаленный репозиторий, сначала нужно к нему подключиться. В нашем руководстве мы будем использовать адрес https://github.com/tutorialzine/awesome-project, но вам посоветуем попробовать создать свой репозиторий в GitHub, BitBucket или любом другом сервисе. Регистрация и установка может занять время, но все подобные сервисы предоставляют хорошую документацию.
Чтобы связать наш локальный репозиторий с репозиторием на GitHub, выполним следующую команду в терминале. Обратите внимание, что нужно обязательно изменить URI репозитория на свой.
# This is only an example. Replace the URI with your own repository address.
$ git remote add origin https://github.com/tutorialzine/awesome-project.git
Проект может иметь несколько удаленных репозиториев одновременно. Чтобы их различать, мы дадим им разные имена. Обычно главный репозиторий называется origin.
2. Отправка изменений на сервер
Сейчас самое время переслать наш локальный коммит на сервер. Этот процесс происходит каждый раз, когда мы хотим обновить данные в удаленном репозитории.
Команда, предназначенная для этого — push. Она принимает два параметра: имя удаленного репозитория (мы назвали наш origin) и ветку, в которую необходимо внести изменения (master — это ветка по умолчанию для всех репозиториев).
$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 212 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/tutorialzine/awesome-project.git
* [new branch] master -> master
В зависимости от сервиса, который вы используете, вам может потребоваться аутентифицироваться, чтобы изменения отправились. Если все сделано правильно, то когда вы посмотрите в удаленный репозиторий при помощи браузера, вы увидете файл hello.txt
3. Клонирование репозитория
Сейчас другие пользователи GitHub могут просматривать ваш репозиторий. Они могут скачать из него данные и получить полностью работоспособную копию вашего проекта при помощи команды clone.
$ git clone https://github.com/tutorialzine/awesome-project.git
Новый локальный репозиторий создается автоматически с GitHub в качестве удаленного репозитория.
4. Запрос изменений с сервера
Если вы сделали изменения в вашем репозитории, другие пользователи могут скачать изменения при помощи команды pull.
$ git pull origin master
From https://github.com/tutorialzine/awesome-project
* branch master -> FETCH_HEAD
Already up-to-date.
Так как новых коммитов с тех пор, как мы склонировали себе проект, не было, никаких изменений доступных для скачивания нет.
Ветвление
Во время разработки новой функциональности считается хорошей практикой работать с копией оригинального проекта, которую называют веткой. Ветви имеют свою собственную историю и изолированные друг от друга изменения до тех пор, пока вы не решаете слить изменения вместе. Это происходит по набору причин:
- Уже рабочая, стабильная версия кода сохраняется.
- Различные новые функции могут разрабатываться параллельно разными программистами.
- Разработчики могут работать с собственными ветками без риска, что кодовая база поменяется из-за чужих изменений.
- В случае сомнений, различные реализации одной и той же идеи могут быть разработаны в разных ветках и затем сравниваться.
1. Создание новой ветки
Основная ветка в каждом репозитории называется master. Чтобы создать еще одну ветку, используем команду branch
$ git branch amazing_new_feature
Это создаст новую ветку, пока что точную копию ветки master.
2. Переключение между ветками
Сейчас, если мы запустим branch, мы увидим две доступные опции:
$ git branch
amazing_new_feature
* master
master — это активная ветка, она помечена звездочкой. Но мы хотим работать с нашей “новой потрясающей фичей”, так что нам понадобится переключиться на другую ветку. Для этого воспользуемся командой checkout, она принимает один параметр — имя ветки, на которую необходимо переключиться.
$ git checkout amazing_new_feature
3. Слияние веток
Наша “потрясающая новая фича” будет еще одним текстовым файлом под названием feature.txt. Мы создадим его, добавим и закоммитим:
$ git add feature.txt
$ git commit -m «New feature complete.”
Изменения завершены, теперь мы можем переключиться обратно на ветку master.
$ git checkout master
Теперь, если мы откроем наш проект в файловом менеджере, мы не увидим файла feature.txt, потому что мы переключились обратно на ветку master, в которой такого файла не существует. Чтобы он появился, нужно воспользоваться merge для объединения веток (применения изменений из ветки amazing_new_feature к основной версии проекта).
$ git merge amazing_new_feature
Теперь ветка master актуальна. Ветка amazing_new_feature больше не нужна, и ее можно удалить.
$ git branch -d awesome_new_feature
Дополнительно
В последней части этого руководства мы расскажем о некоторых дополнительных трюках, которые могут вам помочь.
1. Отслеживание изменений, сделанных в коммитах
У каждого коммита есть свой уникальный идентификатор в виде строки цифр и букв. Чтобы просмотреть список всех коммитов и их идентификаторов, можно использовать команду log:
$ git log
commit ba25c0ff30e1b2f0259157b42b9f8f5d174d80d7
Author: Tutorialzine
Date: Mon May 30 17:15:28 2016 +0300
New feature complete
commit b10cc1238e355c02a044ef9f9860811ff605c9b4
Author: Tutorialzine
Date: Mon May 30 16:30:04 2016 +0300
Added content to hello.txt
commit 09bd8cc171d7084e78e4d118a2346b7487dca059
Author: Tutorialzine
Date: Sat May 28 17:52:14 2016 +0300
Initial commit
Как вы можете заметить, идентификаторы довольно длинные, но для работы с ними не обязательно копировать их целиком — первых нескольких символов будет вполне достаточно. Чтобы посмотреть, что нового появилось в коммите, мы можем воспользоваться командой show [commit]
$ git show b10cc123
commit b10cc1238e355c02a044ef9f9860811ff605c9b4
Author: Tutorialzine
Date: Mon May 30 16:30:04 2016 +0300
Added content to hello.txt
diff —git a/hello.txt b/hello.txt
index e69de29..b546a21 100644
— a/hello.txt
+++ b/hello.txt
@@ -0,0 +1 @@
+Nice weather today, isn’t it?
$ git diff 09bd8cc..ba25c0ff
diff —git a/feature.txt b/feature.txt
new file mode 100644
index 0000000..e69de29
diff —git a/hello.txt b/hello.txt
index e69de29..b546a21 100644
— a/hello.txt
+++ b/hello.txt
@@ -0,0 +1 @@
+Nice weather today, isn’t it?
2. Возвращение файла к предыдущему состоянию
Гит позволяет вернуть выбранный файл к состоянию на момент определенного коммита. Это делается уже знакомой нам командой checkout, которую мы ранее использовали для переключения между ветками. Но она также может быть использована для переключения между коммитами (это довольно распространенная ситуация для Гита — использование одной команды для различных, на первый взгляд, слабо связанных задач).
В следующем примере мы возьмем файл hello.txt и откатим все изменения, совершенные над ним к первому коммиту. Чтобы сделать это, мы подставим в команду идентификатор нужного коммита, а также путь до файла:
$ git checkout 09bd8cc1 hello.txt
3. Исправление коммита
Если вы опечатались в комментарии или забыли добавить файл и заметили это сразу после того, как закоммитили изменения, вы легко можете это поправить при помощи commit —amend. Эта команда добавит все из последнего коммита в область подготовленных файлов и попытается сделать новый коммит. Это дает вам возможность поправить комментарий или добавить недостающие файлы в область подготовленных файлов.
Для более сложных исправлений, например, не в последнем коммите или если вы успели отправить изменения на сервер, нужно использовать revert. Эта команда создаст коммит, отменяющий изменения, совершенные в коммите с заданным идентификатором.
Самый последний коммит может быть доступен по алиасу HEAD:
Для остальных будем использовать идентификаторы:
$ git revert b10cc123
При отмене старых коммитов нужно быть готовым к тому, что возникнут конфликты. Такое случается, если файл был изменен еще одним, более новым коммитом. И теперь git не может найти строчки, состояние которых нужно откатить, так как они больше не существуют.
4. Разрешение конфликтов при слиянии
Помимо сценария, описанного в предыдущем пункте, конфликты регулярно возникают при слиянии ветвей или при отправке чужого кода. Иногда конфликты исправляются автоматически, но обычно с этим приходится разбираться вручную — решать, какой код остается, а какой нужно удалить.
Давайте посмотрим на примеры, где мы попытаемся слить две ветки под названием john_branch и tim_branch. И Тим, и Джон правят один и тот же файл: функцию, которая отображает элементы массива.
Джон использует цикл:
// Use a for loop to console.log contents.
for(var i=0; iconsole.log(arr[i]);
>
Тим предпочитает forEach:
// Use forEach to console.log contents.
arr.forEach(function(item) <
console.log(item);
>);
Они оба коммитят свой код в соответствующую ветку. Теперь, если они попытаются слить две ветки, они получат сообщение об ошибке:
$ git merge tim_branch
Auto-merging print_array.js
CONFLICT (content): Merge conflict in print_array.js
Automatic merge failed; fix conflicts and then commit the result.
Система не смогла разрешить конфликт автоматически, значит, это придется сделать разработчикам. Приложение отметило строки, содержащие конфликт:
Над разделителем ======= мы видим последний (HEAD) коммит, а под ним — конфликтующий. Таким образом, мы можем увидеть, чем они отличаются и решать, какая версия лучше. Или вовсе написать новую. В этой ситуации мы так и поступим, перепишем все, удалив разделители, и дадим git понять, что закончили.
// Not using for loop or forEach.
// Use Array.toString() to console.log contents.
console.log(arr.toString());
Когда все готово, нужно закоммитить изменения, чтобы закончить процесс:
$ git add -A
$ git commit -m «Array printing conflict resolved.»
Как вы можете заметить, процесс довольно утомительный и может быть очень сложным в больших проектах. Многие разработчики предпочитают использовать для разрешения конфликтов клиенты с графическим интерфейсом. (Для запуска нужно набрать git mergetool).
5. Настройка .gitignore
В большинстве проектов есть файлы или целые директории, в которые мы не хотим (и, скорее всего, не захотим) коммитить. Мы можем удостовериться, что они случайно не попадут в git add -A при помощи файла .gitignore
- Создайте вручную файл под названием .gitignore и сохраните его в директорию проекта.
- Внутри файла перечислите названия файлов/папок, которые нужно игнорировать, каждый с новой строки.
- Файл .gitignore должен быть добавлен, закоммичен и отправлен на сервер, как любой другой файл в проекте.
Вот хорошие примеры файлов, которые нужно игнорировать:
- Логи
- Артефакты систем сборки
- Папки node_modules в проектах node.js
- Папки, созданные IDE, например, Netbeans или IntelliJ
- Разнообразные заметки разработчика.
Файл .gitignore, исключающий все перечисленное выше, будет выглядеть так:
Символ слэша в конце некоторых линий означает директорию (и тот факт, что мы рекурсивно игнорируем все ее содержимое). Звездочка, как обычно, означает шаблон.
Заключение
Вот и все! Наше руководство окончено. Мы очень старались собрать всю самую важную информацию и изложить ее как можно более сжато и кратко.
Git довольно сложен, и в нем есть еще много функций и трюков. Если вы хотите с ними познакомиться, вот некоторые ресурсы, которые мы рекомендуем:
- Официальная документация, включающая книгу и видеоуроки – тут .
- “Getting git right” – Коллекция руководств и статей от Atlassian – тут .
- Список клиентов с графическим интерфейсом – тут .
- Онлайн утилита для генерации .gitignore файлов – тут .