-
1. Вступ
- 1.1 Про систему контролю версій
- 1.2 Коротка історія Git
- 1.3 Основи Git
- 1.4 Git, зазвичай, тільки додає дані
- 1.5 Три стани
- 1.6 Командний рядок
- 1.7 Інсталяція Git
- 1.8 Початкове налаштування Git
- 1.9 Отримання допомоги
- 1.10 Підсумок
-
2. Основи Git
- 2.1 Створення Git-репозиторія
- 2.2 Запис змін до репозиторія
- 2.3 Перегляд історії комітів
- 2.4 Скасування речей
- 2.5 Взаємодія з віддаленими сховищами
- 2.6 Теґування
- 2.7 Псевдоніми Git
- 2.8 Підсумок
-
3. Галуження в git
- 3.1 Гілки у кількох словах
- 3.2 Основи галуження та зливання
- 3.3 Управління гілками
- 3.4 Процеси роботи з гілками
- 3.5 Віддалені гілки
- 3.6 Перебазовування
- 3.7 Підсумок
-
4. Git на сервері
- 4.1 Протоколи
- 4.2 Отримання Git на сервері
- 4.3 Генерація вашого публічного ключа SSH
- 4.4 Налаштування Серверу
- 4.5 Демон Git
- 4.6 Розумний HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Варіанти стороннього хостингу
- 4.10 Підсумок
-
5. Розподілений Git
-
6. GitHub
-
7. Інструменти Git
- 7.1 Вибір ревізій
- 7.2 Інтерактивне індексування
- 7.3 Ховання та чищення
- 7.4 Підписання праці
- 7.5 Пошук
- 7.6 Переписування історії
- 7.7 Усвідомлення скидання (reset)
- 7.8 Складне злиття
- 7.9 Rerere
- 7.10 Зневадження з Git
- 7.11 Підмодулі
- 7.12 Пакування
- 7.13 Заміна
- 7.14 Збереження посвідчення (credential)
- 7.15 Підсумок
-
8. Налаштування Git
-
9. Git and Other Systems
- 9.1 Git як клієнт
- 9.2 Міграція на Git
- 9.3 Підсумок
-
10. Git зсередини
- 10.1 Кухонні та парадні команди
- 10.2 Об’єкти Git
- 10.3 Посилання Git
- 10.4 Файли пакунки
- 10.5 Специфікація посилань (refspec)
- 10.6 Протоколи передачі
- 10.7 Супроводження та відновлення даних
- 10.8 Змінні середовища
- 10.9 Підсумок
-
A1. Додаток A: Git в інших середовищах
- A1.1 Графічні інтерфейси
- A1.2 Git у Visual Studio
- A1.3 Git в Eclipse
- A1.4 Git у Bash
- A1.5 Git у Zsh
- A1.6 Git у Powershell
- A1.7 Підсумок
-
A2. Додаток B: Вбудовування Git у ваші застосунки
- A2.1 Git з командного рядка
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
-
A3. Додаток C: Команди Git
- A3.1 Налаштування та конфігурація
- A3.2 Отримання та створення проектів
- A3.3 Базове збереження відбитків
- A3.4 Галуження та зливання
- A3.5 Поширення й оновлення проектів
- A3.6 Огляд та порівняння
- A3.7 Зневаджування
- A3.8 Латання (patching)
- A3.9 Електронна пошта
- A3.10 Зовнішні системи
- A3.11 Адміністрування
- A3.12 Кухонні команди
7.14 Інструменти Git - Збереження посвідчення (credential)
Збереження посвідчення (credential)
Якщо ви використовуєте протокол SSH для зʼєднання з віддаленими сховищами, то можете використовувати ключ без пароля, що дозволяє безпечно передавати дані без набирання імʼя користувача та пароля. Втім, це неможливо з HTTP протоколами – кожне зʼєднання потребує імені та пароля. Все стає ще складнішим з двокроковою авторизацією: значення, яке треба використати як пароль, випадково згенероване та невимовне.
На щастя, Git має систему посвідчень, яка може тут зарадити. Щойно встановлений Git пропонує чимало опцій:
-
Типова поведінка — взагалі нічого не запамʼятовувати. Кожне зʼєднання потребує від вас імʼя користувача та пароль.
-
Режим “cache” зберігає посвідчення в памʼяті визначений термін. Жоден пароль не зберігається на диску, та вичищається з памʼяті за 15 хвилин.
-
Режим “store” зберігає посвідчення до простого текстового файлу на диску, та ніколи не застаріває. Це означає, що доки ви не зміните пароль для Git, вам ніколи не доведеться набирати ваші дані знов. Недоліком цього методу є те, що ваші паролі зберігаються текстом у простому файлі в домашній директорії.
-
Якщо ви використовуєте Mac, Git має режим “osxkeychain”, який зберігає посвідчення у безпечному ланцюгу ключів (keychain), що є привʼязаним до вашого системного облікового запису. Цей метод зберігає посвідчення на диску і ніколи не застаріває, проте його зашифровано так само, як система зберігає сертифікати HTTPS та автозаповнювачі Safari.
-
Якщо ви використовуєте Windows, то можете встановити помічник (helper) під назвою “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
, яка приймає команду в якості аргументу, а потім ще ввід через stdin.
Можливо це легше зрозуміти за допомогою прикладу.
Припустімо, помічник посвідчень вже налаштовано, та він вже зберіг посвідчення для mygithost
.
Ось сесія, що використовує команду “fill”, яка викликається при спробі знайти посвідчення для хосту:
$ 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 очікує вводу з stdin. Ми кажемо йому що знаємо: протокол та імʼя хосту.
-
Порожній рядок означає, що ввід завершено, та система посвідчень має відповісти, що вона знає.
-
Далі Git-credential приймає керування та пише до stdout інформацію, яку знайшов.
-
Якщо посвідчень не знайдено, Git запитує в користувача імʼя та пароль, та видає їх назад до stdout, з якого був викликаний (у даному випадку вони підʼєднані до однієї консолі).
Насправді, система посвідчень викликає програму, яка відокремлена від власно Git; яку саме залежить від значення налаштування credential.helper
.
Ось декілька форм, які воно може мати:
Значення налаштування | Поведінка |
---|---|
|
Виконує |
|
Виконує |
|
Виконує |
|
Код після |
Отже, вищеописані помічники насправді мають назви git-credential-cache
, git-credential-store
тощо, та ми можемо їх налаштувати, щоб вони приймали аргументи командного рядка.
Загальна форма для цього “git-credential-foo [аргументи] <дія>.”
Протокол stdin/stdout такий самий, як для git-credential, проте вони використовують трохи інших набір дій:
-
get
— це запит пари імені/пароля. -
store
— це запит на зберігання набору посвідчень у памʼяті помічника. -
erase
— очистити посвідчення для наданих властивостей з памʼяті помічника.
Для дій store
та erase
відповідь не потрібна (Git все одно її ігнорує).
Втім, щодо дії get
, Git дуже зацікавлений у тому, що скаже помічник.
Якщо помічник не знає нічого корисного, він може просто вийти без виводу, проте, якщо він щось знає, він має доповнити прийняту інформацію тою, яку зберіг.
Вивід сприймається як послідовність виразів присвоєння; будь-що надане замінить те, що 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
використовують локальний формат своїх cховищ, у той час як 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
та файл з даними існує. -
Цей цикл читає з stdin доки не зустріне перший порожній рядок. Вхід зберігається в хеші
known
для подальшого використання. -
Цей цикл читає вміст файлу з даними — шукає відповідності. Якщо протокол та хост з
known
відповідають поточному рядку, програма друкує результати до stdout та завершує свою роботу.
Ми збережемо наш помічник як 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'
Як ви можете бачити, розширення системи є доволі прямолінійним, та може вирішувати якісь повсякденні завдання для вас та вашої команди.