-
1. Начало
- 1.1 За Version Control системите
- 1.2 Кратка история на Git
- 1.3 Какво е Git
- 1.4 Конзолата на Git
- 1.5 Инсталиране на Git
- 1.6 Първоначална настройка на Git
- 1.7 Помощна информация в Git
- 1.8 Обобщение
-
2. Основи на Git
-
3. Клонове в Git
-
4. Git на сървъра
- 4.1 Комуникационни протоколи
- 4.2 Достъп до Git на сървъра
- 4.3 Генериране на SSH публичен ключ
- 4.4 Настройка на сървъра
- 4.5 Git Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Други опции за хостване
- 4.10 Обобщение
-
5. Git в разпределена среда
-
6. GitHub
-
7. Git инструменти
- 7.1 Избор на къмити
- 7.2 Интерактивно индексиране
- 7.3 Stashing и Cleaning
- 7.4 Подписване на вашата работа
- 7.5 Търсене
- 7.6 Манипулация на историята
- 7.7 Мистерията на командата Reset
- 7.8 Сливане за напреднали
- 7.9 Rerere
- 7.10 Дебъгване с Git
- 7.11 Подмодули
- 7.12 Пакети в Git (Bundling)
- 7.13 Заместване
- 7.14 Credential Storage система
- 7.15 Обобщение
-
8. Настройване на Git
- 8.1 Git конфигурации
- 8.2 Git атрибути
- 8.3 Git Hooks
- 8.4 Примерна Git-Enforced политика
- 8.5 Обобщение
-
9. Git и други системи
- 9.1 Git като клиент
- 9.2 Миграция към Git
- 9.3 Обобщение
-
10. Git на ниско ниво
- 10.1 Plumbing и Porcelain команди
- 10.2 Git обекти
- 10.3 Git референции
- 10.4 Packfiles
- 10.5 Refspec спецификации
- 10.6 Транспортни протоколи
- 10.7 Поддръжка и възстановяване на данни
- 10.8 Environment променливи
- 10.9 Обобщение
-
A1. Приложение A: Git в други среди
- A1.1 Графични интерфейси
- A1.2 Git във Visual Studio
- A1.3 Git във Visual Studio Code
- A1.4 Git in IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git в Sublime Text
- A1.6 Git в Bash
- A1.7 Git в Zsh
- A1.8 Git в PowerShell
- A1.9 Обобщение
-
A2. Приложение B: Вграждане на Git в приложения
- A2.1 Git от команден ред
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Приложение C: Git команди
- A3.1 Настройки и конфигурация
- A3.2 Издърпване и създаване на проекти
- A3.3 Snapshotting
- A3.4 Клонове и сливане
- A3.5 Споделяне и обновяване на проекти
- A3.6 Инспекция и сравнение
- A3.7 Дебъгване
- A3.8 Patching
- A3.9 Email команди
- A3.10 Външни системи
- A3.11 Административни команди
- A3.12 Plumbing команди
4.6 Git на сървъра - Smart HTTP
Smart HTTP
Вече имаме автентикиран достъп през SSH и неавтентикиран през git://
протокола, но съществува и протокол, който може да прави и двете едновременно.
Процесът по настройка на Smart HTTP всъщност се свежда до разрешаването на CGI скрипт, който идва с Git и е известен като git-http-backend
на сървъра.
Този скрипт ще чете пътя и хедърите изпратени от git fetch
или git push
към HTTP URL и ще разбере дали клиентът може да комуникира през http (което е така за всеки клиент след версия 1.6.6).
Ако CGI скриптът види, че клиентът е смарт, той ще комуникира с него по интелигентен начин. В противен случай, ще се върне към по-опростения способ (така че да е обратно съвместим с по-старите клиенти).
Нека минем през съвсем простата настройка. Ще използваме Apache като CGI сървър. Ако нямате настроен Apache, можете да го направите в Linux система приблизително така:
$ sudo apt-get install apache2 apache2-utils
$ a2enmod cgi alias env
Това ще разреши модулите mod_cgi
, mod_alias
, и mod_env
, които са необходими за нашите цели.
Ще трябва също така да промените групата на директориите в /srv/git
на www-data
, така че уеб сървърът да има права за четене и писане в хранилищата, защото инстанцията на Apache, която ще изпълнява CGI скрипта, ще работи по подразбиране като този потребител:
$ chgrp -R www-data /srv/git
След това трябва да променим някои неща по конфигурацията на Apache, така че да използва git-http-backend
скрипта като средство за обработка на всички заявки, идващи в /git
пътя на уеб сървъра.
SetEnv GIT_PROJECT_ROOT /srv/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/lib/git-core/git-http-backend/
Ако оставите променливата GIT_HTTP_EXPORT_ALL
, тогава Git ще допуска неавтентикираните потребители само до хранилищата, съдържащи файла git-daemon-export-ok
- точно както го прави и Git демона.
Накрая, ще искаме да накараме Apache да позволява заявки от автентикирани потребители с права на запис към git-http-backend
с блок подобен на следния:
<Files "git-http-backend">
AuthType Basic
AuthName "Git Access"
AuthUserFile /srv/git/.htpasswd
Require expr !(%{QUERY_STRING} -strmatch '*service=git-receive-pack*' || %{REQUEST_URI} =~ m#/git-receive-pack$#)
Require valid-user
</Files>
Това значи, че трябва да създадете .htpasswd
файл, съдържащ паролите за всички валидни потребители.
Ето пример за добавен потребител “schacon” в такъв файл:
$ htpasswd -c /srv/git/.htpasswd schacon
Има много различни начини да накарате Apache да автентикира потребители, просто трябва да изберете подходящия за вас. Тук просто посочихме един от най-простите варианти. Вероятно също ще искате да настроите достъп през SSL, така че комуникацията да е криптирана.
Няма да навлизаме по-навътре в конфигурационните детайли на Apache, тъй като може да използвате различни похвати за автентикация или изцяло различен уеб сървър.
Идеята е, че Git идва с CGI скрипт наречен git-http-backend
, който когато бъде извикан, ще поеме цялата комуникация по приемането и изпращането на данни през HTTP.
Самият скрипт не извършва сам по себе си никаква автентикация, но това може лесно да бъде контролирано при уеб сървъра, който го извиква.
Можете да го използвате почти с всеки CGI уеб сървър, така че изберете този, който предпочитате.
Забележка
|
За повече информация за настройка на Apache, вижте документацията тук: https://httpd.apache.org/docs/current/howto/auth.html |