-
1. Почеток
- 1.1 За верзиска контрола
- 1.2 Кратка историја на Git
- 1.3 Основи на Гит
- 1.4 Командната линија
- 1.5 Инсталирање на Git
- 1.6 First-Time Git Setup
- 1.7 Getting Help
- 1.8 Заклучок
-
2. Основите на Git
-
3. Гранење во Git
- 3.1 Гранење објаснето
- 3.2 Основно разгранување и спојување
- 3.3 Branch Management
- 3.4 Работни процеси
- 3.5 Далечински гранки
- 3.6 Ребаза
- 3.7 Заклучок
-
4. Git на Сервер
- 4.1 Протоколите
- 4.2 Добивање на Git на сервер
- 4.3 Генерирање на вашиот SSH јавен клуч
- 4.4 Поставување на серверот
- 4.5 Гит демон
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Опции за домаќини на трети лица
- 4.10 Заклучок
-
5. Дистрибуиран Git
- 5.1 Дистрибуирани работни процеси
- 5.2 Придонес кон проект
- 5.3 Приватен мал тим
- 5.4 Одржување на проект
- 5.5 Заклучок
-
6. GitHub
-
7. Git Алатки
- 7.1 Revision Selection
- 7.2 Интерактивно стажирање
- 7.3 Stashing and Cleaning
- 7.4 Signing Your Work
- 7.5 Searching
- 7.6 Rewriting History
- 7.7 Reset Demystified
- 7.8 Напредно спојување
- 7.9 Rerere
- 7.10 Дебагирање со Git
- 7.11 Submodules
- 7.12 Збивање
- 7.13 Заменување
- 7.14 Складирање на ингеренции
- 7.15 Заклучок
-
8. Персонализација на Git
- 8.1 Git Configuration
- 8.2 Git Атрибути
- 8.3 Git Hooks
- 8.4 An Example Git-Enforced Policy
- 8.5 Заклучок
-
9. Git и други системи
- 9.1 Git како Клиент
- 9.2 Мигрирање кон Git
- 9.3 Заклучок
-
10. Внатрешноста на Git
- 10.1 Plumbing and Porcelain
- 10.2 Git Objects
- 10.3 Git References
- 10.4 Packfiles
- 10.5 The Refspec
- 10.6 Transfer Protocols
- 10.7 Maintenance and Data Recovery
- 10.8 Environment Variables
- 10.9 Заклучок
-
A1. Appendix A: Git во други околини
- A1.1 Graphical Interfaces
- A1.2 Git in Visual Studio
- A1.3 Git in Eclipse
- A1.4 Git in Bash
- A1.5 Git in Zsh
- A1.6 Git in Powershell
- A1.7 Заклучок
-
A2. Appendix B: Вметнување на Git во вашите апликации
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
-
A3. Appendix C: Git команди
- A3.1 Setup and Config
- A3.2 Getting and Creating Projects
- A3.3 Basic Snapshotting
- A3.4 Branching and Merging
- A3.5 Sharing and Updating Projects
- A3.6 Inspection and Comparison
- A3.7 Debugging
- A3.8 Patching
- A3.9 Email
- A3.10 External Systems
- A3.11 Administration
- A3.12 Plumbing Commands
7.14 Git Алатки - Складирање на ингеренции
Складирање на ингеренции
Ако го користите транспортот за SSH за поврзување со далечински управувачи, можно е да имате клуч без тајна фраза, која овозможува безбедно пренесување на податоци без напишување на вашето корисничко име и лозинка. Сепак, ова не е можно со HTTP протоколите - секоја врска му треба корисничко име и лозинка. Ова станува уште потешко за системи со двофакторска автентикација, каде токен што го користите за лозинка е случајно генерирана и непроверлива.
За среќа, Git има систем за проверка на квалификации кој може да помогне во тоа. Git има неколку опции наведени во полето:
-
Стандардното не е да се кешира воопшто. Секоја конекција ќе ве прашува за вашето корисничко име и лозинка.
-
Режимот ‘` кеш '’ ги задржува акредитивите во меморијата за одреден временски период. Ниту една од лозинките никогаш не е зачувана на дискот, и тие се очисти од кешот по 15 минути.
-
Режимот ‘` store '’ ги зачувува акредитивните писма на обичен текстуален фајл на дискот и никогаш не истекуваат. Ова значи дека додека не ја смените лозинката за домаќинот Git, никогаш нема да морате повторно да ги внесувате вашите ингеренции. Недостатоци на овој пристап е дека вашите лозинки се зачувани во чист текст во обична датотека во вашиот домашен директориум.
-
Ако користите Mac, Git доаѓа со ‘` osxkeychain '’ режим, кој ги кешира акредитивните писма во безбедносниот приврзок со клучеви кој е прикачен на вашата системска сметка. Овој метод ги зачувува ингеренциите на дискот и тие никогаш не истекуваат, но тие се шифрирани со истиот систем кој ги зачувува HTTPS-сертификатите и авто-пополнувањата на Safari.
-
Ако користите Windows, можете да инсталирате помошник наречен ‘` Git Credential Manager for Windows. '’ Ова е слично на помошник "osxkeychain", кој е опишан погоре, но го користи Продавницата за Credential на Windows за да ги контролира чувствителните информации. Може да се најдат на https://github.com/Microsoft/Git-Credential-Manager-for-Windows [].
Можете да изберете еден од овие методи со поставување на вредноста на конфигурацијата Git:
$ git config --global credential.helper cache
Некои од овие помошници имаат опции.
Помошник за "чување" може да земе аргумент --file <path>
, кој се прилагодува каде што е зачувана обичната текстуална датотека (стандардно е ~ / .git-credentials
).
Помошник за "кеш" ја прифаќа опцијата --timeout <seconds>
, која го менува времето во кое неговиот демон продолжува да работи (стандардно е ‘` 900 '’ или 15 минути).
Еве еден пример за тоа како би го конфигурирале помошникот "чувар" со сопствено име на датотека:
$ 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 се обидува да најде ингеренции за домаќин:
$ 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" конфигурациската вредност. Постојат неколку форми што може да ги преземе:
Configuration Value | Behavior |
---|---|
|
Runs |
|
Runs |
|
Runs |
|
Code after |
Значи помошниците опишани погоре се всушност именувани како "git-credential-cache", "git-credential-store" и така натаму, и можеме да ги конфигурираме да ги преземеме командните аргументи. Општата форма за ова е ‘` git-credential-foo [args] <action>. '’ Протоколот stdin / stdout е ист како git-ингеренција, но тие користат нешто различно множество акции:
-
get
е барање за пар на корисничко име / лозинка. -
store
е барање за зачувување на збир на ингеренциите во меморијата на овој помошник. -
"Избриши" исчистете ги ингеренциите за дадените својства од меморијата на овој помошник.
За постапките store
и` erase`, не е потребен одговор (Git тоа го игнорира).
За get
акцијата, сепак, Git е многу заинтересиран за она што помошникот има да каже.
Ако помошникот не знае ништо корисно, едноставно може да излезе без излез, но ако знае, треба да ги зголеми информациите што ги обезбедил со информациите што ги има складирано.
Излезот се третира како серија на извештаи за доделување; сè што е предвидено ќе го замени она што Гит веќе го знае.
Еве го истиот пример од погоре, но прескокнувајќи го Git-акредитив и одејќи директно за 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, тоа не е голем скок за да сфатиме дека any програмата може да биде помошник за 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 додека не се постигне првата празна линија. Влезовите се зачувани во
позната
хаш за подоцнежна референца. -
Оваа јамка ја чита содржината на датотеката за складирање, барајќи натпревари. Ако протоколот и домаќин од "познат" се совпаѓаат со оваа линија, програмата ги печати резултатите во 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'
Како што можете да видите, проширувањето на овој систем е прилично едноставно и може да реши некои заеднички проблеми за вас и за вашиот тим.