-
1. Почетак
- 1.1 О контроли верзије
- 1.2 Кратка историја програма Гит
- 1.3 Шта је Гит?
- 1.4 Командна линија
- 1.5 Инсталирање програма Гит
- 1.6 Подешавања за први пут
- 1.7 Тражење помоћи
- 1.8 Резиме
-
2. Основе програма Гит
- 2.1 Прављење Гит репозиторијума
- 2.2 Снимање промена над репозиторијумом
- 2.3 Преглед историје комитова
- 2.4 Опозив
- 2.5 Рад са удаљеним репозиторијумима
- 2.6 Означавање
- 2.7 Гит алијаси
- 2.8 Резиме
-
3. Гранање у програму Гит
- 3.1 Укратко о гранању
- 3.2 Основе гранања и спајања
- 3.3 Управљање гранама
- 3.4 Процеси рада са гранањем
- 3.5 Удаљене гране
- 3.6 Ребазирање
- 3.7 Резиме
-
4. Гит на серверу
- 4.1 Протоколи
- 4.2 Постављање програма Гит на сервер
- 4.3 Генерисање јавног SSH кључа
- 4.4 Подешавање сервера
- 4.5 Гит демон
- 4.6 Паметан HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Опције за хостовање које нуде трећа лица
- 4.10 Резиме
-
5. Дистрибуирани Гит
-
6. GitHub
-
7. Гит алати
- 7.1 Избор ревизија
- 7.2 Интерактивно стејџовање
- 7.3 Скривање и чишћење
- 7.4 Потписивање вашег рада
- 7.5 Претрага
- 7.6 Поновно исписивање историје
- 7.7 Демистификовани ресет
- 7.8 Напредно спајање
- 7.9 Rerere
- 7.10 Отклањање грешака са програмом Git
- 7.11 Подмодули
- 7.12 Паковање
- 7.13 Замена
- 7.14 Складиште акредитива
- 7.15 Резиме
-
8. Прилагођавање програма Гит
- 8.1 Конфигурисање програма Гит
- 8.2 Гит атрибути
- 8.3 Гит куке
- 8.4 Пример полисе коју спроводи програм Гит
- 8.5 Резиме
-
9. Гит и остали системи
- 9.1 Гит као клијент
- 9.2 Мигрирање на Гит
- 9.3 Резиме
-
10. Гит изнутра
- 10.1 Водовод и порцелан
- 10.2 Гит објекти
- 10.3 Гит референце
- 10.4 Pack фајлови
- 10.5 Рефспек
- 10.6 Протоколи за пренос
- 10.7 Одржавање и опоравак податак
- 10.8 Променљиве окружења
- 10.9 Резиме
-
A1. Додатак А: Програм Гит у другим окружењима
- A1.1 Графички интерфејси
- A1.2 Гит у Visual Studio
- A1.3 Гит у Visual Studio Code
- A1.4 Гит у IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Гит у Sublime Text
- A1.6 Гит унутар Bash
- A1.7 Гит у Zsh
- A1.8 Гит у Powershell
- A1.9 Резиме
-
A2. Додатак Б: Уграђивање програма Гит у ваше апликације
- A2.1 Гит из командне линије
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Додатак В: Гит команде
- A3.1 Подешавање и конфигурација
- A3.2 Набављање и креирање пројеката
- A3.3 Основно снимање
- A3.4 Гранање и спајање
- A3.5 Дељење и ажурирање пројеката
- A3.6 Инспекција и поређење
- A3.7 Отклањање грешака
- A3.8 Крпљење
- A3.9 Имејл
- A3.10 Спољни системи
- A3.11 Администрација
- A3.12 Водоводне команде
7.14 Гит алати - Складиште акредитива
Складиште акредитива
Ако за повезивање на удаљене репозиторијуме користите SSH транспорт, могуће је да имате кључ без вишеделне лозинке који вам омогућава да безбедно преносите податке без потребе уноса корисничког имена и лозинке. Међутим, ово није могуће са HTTP протоколима – за сваку везу је неопходно корисничко име и лозинка. Ово постаје још теже за системе са двофакторском аутентификацијом код којих се токен коришћен за лозинку генерише насумично и не може да се изговори.
На срећу, програм Гит поседује систем акредитива који вам помаже у оваквим ситуацијама. Програм Гит нуди неколико уграђених опција:
-
Акредитиви се подразумевано не кеширају. Приликом сваког повезивања бићете упитани за своје корисничко име и лозинку.
-
„cache” режим чува акредитиве у меморији на одређени период. Ниједна лозинка се никада не чува на диск и уклањају се из кеша након 15 минута.
-
„store” режим чува акредитиве у фајлу на диск као чисти текст и никада не истичу. Ово значи да докле год не промените своју лозинку за Гит хост, више нећете морати поново да уносите своје акредитиве. Мана овог приступа је што се нешифриране лозинке чувају у чистом фајлу који се налази у вашем почетном директоријуму.
-
Ако користите Мек, програм Гит долази са „osxkeychain” режимом који акредититве кешира у сигурном привеску за кључеве (keychain) који је везан са ваш системски налог. Ова метода чува акредитиве на диск и они никада не истичу, али су шифровани истим системом који чува HTTPS сертификате и аутоматска попуњавања за програм Сафари.
-
Ако користите Виндоуз, мекОС, или Линукс, можете да инсталирате помоћник под називом „Git Credential Manager”. Он за контролу осетљивих информација користи складишта података развијена за дату платформу.
Неку од ових метода можете изабрати тако што поставите Гит конфигурациону вредност:
$ git config --global credential.helper cache
Неки од ових помоћника имају опције.
„store” помоћник може да прихвати --file <путања>
аргумент који прилагођава место чувања фајла са чистим текстом (подразумевана вредност је ~/.git-credentials
).
„cache” помоћник прихвата опцију --timeout <секунди>
која мења време током којег даемон наставља са извршавањем (подразумевана вредност је „900”, или 15 минута).
Ево примера како да за „store” помоћник подсетите жељено име фајла:
$ git config --global credential.helper store --file ~/.my-credentials
Програм Гит вам чак дозвољава да подесите и неколико помоћника.
Када тражи акредитиве за одређени хост, програм Гит ће питати помоћнике редом и зауставиће се када прими први одговор.
Када чува акредитиве, програм Гит ће послати корисничко име и лозинку свим помоћницима са листе, па они могу одлучити шта да раде са тим подацима.
Ево како би изгледао .gitconfig
ако имате фајл са акредитивима на флеш драјву, али желите да користите кеш у меморији како не бисте морали да куцате када драјв није у порту:
[credential]
helper = store --file /mnt/thumbdrive/.git-credentials
helper = cache --timeout 30000
Испод хаубе
Како све ово функционише?
Основна команда програма Гит за систем помоћника за акредитиве је 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 делиће информације коју је пронашао.
-
Ако се акредитиви не пронађу, програм Гит тражи од корисника да унесе корисничко име и лозинку, па иг доставља назад позивајућем stdout (овде су они прикачени на исту конзолу).
Систем акредитива уствари позива програм који није део самог програма Гит; који је то програм, зависи од вредности конфигурационе променљиве credential.helper
.
Она може узети неколико облика:
Вредност конф. променљиве | Понашање |
---|---|
|
Покреће |
|
Покреће |
|
Покреће |
|
Кôд након |
Тако да се помоћници описани изнад уствари називају git-credential-cache
, git-credential-store
и тако даље, па можемо да их конфигуришемо тако да узимају аргументе из команде.
Општи облик за ово је git-credential-foo [арг] <акција>
.
stdin/stdout протокол је исти као за git-credential, само што користе донекле измењени скуп акција:
-
get
је захтев за пар корисничко_име/лозинка. -
store
је захтев за чување скупа акредитива у меморији помоћника. -
erase
чисти акредитиве за дате особине из меморије помоћника.
Одговор није обавезан за store
и erase
акције (програм Гит га ионако игнорише).
Међутим, у случају get
акције, програм Гит је веома заинтересован да чује шта помоћник има да каже.
Ако помоћник не зна било шта корисно, он једноставно може да заврши извршавање без икаквог излаза, али ако зна, требало би да достављену информацију допуни са сачуваним подацима.
Излаз се третира као низ наредби доделе; све што се достави ће заменити оно што програм Гит већ зна.
Ево ситог примера као малопре, само што прескачемо 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
и winstore
користе нативни формат својих складишта, док cache
користи свој сопствени формат у меморији (који ниједан други процес не може да прочита).
Прилагођени кеш акредитива
Како су git-credential-store
и пријатељи програми одвојени од програма Гит, не треба пуно вештине да се схвати како било који програм може бити Гит помоћник за акредитиве.
Помоћници које обезбеђује програм Гит покривају многе уобичајене случајеве употребе, али не све.
На пример, рецимо да ваш тима има неке акредитиве које дели цео тим, вероватно за постављање.
Они се чувају у дељеном директоријуму, али не желите да их копирате у своје складиште акредитива јер се често мењају.
Овај случај употребе не покрива ниједан од постојећих помоћника; па хајде да видимо шта је потребно да напишете сопствени.
Постоји неколико кључних могућности које овај програм мора да поседује:
-
Једина акција на коју треба да обратимо пажњу је
get
;store
иerase
су операције уписа, па када их примимо просто ћемо на чист начин да завршимо извршавање. -
Формат дељеног фајла акредитива је исти као онај који користи
git-credential-store
. -
Локација тог фајла је прилично стандардна, али би кориснику за сваки случај ипак требало да омогућимо прослеђивање прилагођене путање.
И овога пута ћемо проширење написати у језику Руби, мада функционише било који језик све док програм Гит буде у стању да изврши завршени производ. Ево комплетног изворног кода нашег новог помоћника за акредитиве:
#!/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'] 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
username=bob
protocol=https
host=mygithost
username=bob
password=s3cre7
Пошто име почиње на „git-”, за вредност конфигурационе променљиве можемо употребити једноставну синтаксу:
$ git config --global credential.helper 'read-only --file /mnt/shared/creds'
Као што видите, проширивање овог система је прилично једноставно и вама и вашем тиму може решити неке честе проблеме.