-
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.4 Git на сървъра - Настройка на сървъра
Настройка на сървъра
Нека преминем през настройката на SSH достъпа от страна на сървъра.
В този пример, ще използвате метода authorized_keys
за автентикиране на вашите потребители.
Подразбираме също така, че използвате стандартна Linux дистрибуция, например Ubuntu.
Забележка
|
Голяма част от описаното тук може да се автоматизира с командата |
Първо, създавате git
потребител и .ssh
директория за него.
$ sudo adduser git
$ su git
$ cd
$ mkdir .ssh && chmod 700 .ssh
$ touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys
След това, трябва да добавите няколко публични ключа на разработчици към файла authorized_keys
на потребителя git
.
Нека кажем, че имате няколко такива ключа и ги съхранявате във временни файлове.
Да припомним, публичните ключове изглеждат така:
$ cat /tmp/id_rsa.john.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L
ojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k
Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez
Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv
O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq
dAv8JggJICUvax2T9va5 gsg-keypair
Просто трябва да ги добавите към authorized_keys
файла на потребителя git
в .ssh
директорията му:
$ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys
Сега можете да инициализирате празно хранилище за тях изпълнявайки git init
с опцията --bare
, което ще създаде хранилище без работна директория:
$ cd /srv/git
$ mkdir project.git
$ cd project.git
$ git init --bare
Initialized empty Git repository in /srv/git/project.git/
След като направите това, John, Josie, или Jessica могат да изпратят първата версия на своя проект в това хранилище като го добавят като отдалечено и изпратят някой клон.
Отбележете, че е необходимо някой да се логва в тази машина и да създава празно хранилище всеки път, когато искате да добавите проект.
Нека ползваме gitserver
за име на сървъра, който настроихме.
Ако го използвате само локално и настроите DNS сървъра си да сочи към адреса му, тогава може да използвате командите буквално така (подразбираме, че myproject
е съществуващ проект с файлове):
# от компютъра на John
$ cd myproject
$ git init
$ git add .
$ git commit -m 'Initial commit'
$ git remote add origin git@gitserver:/srv/git/project.git
$ git push origin master
Сега вече другите могат да клонират проекта и да изпращат промени към него също така лесно:
$ git clone git@gitserver:/srv/git/project.git
$ cd project
$ vim README
$ git commit -am 'Fix for README file'
$ git push origin master
Ползвайки този подход можете лесно да пуснете read/write Git сървър за малък екип разработчици.
Следва да сте забелязали, че сега всички тези потребители могат също така да се логнат на сървъра като потребител git
.
Ако искате да ограничите това, ще трябва да смените шела на git
с нещо различно във файла /etc/passwd
.
Можете лесно да ограничите git
потребителя само до Git дейности с рестриктивния инструмент git-shell
, който идва с Git.
Ако го използвате за login шел за вашия git
потребител, то той ще има доста по-ограничени права в сървъра.
Просто използвайте git-shell
вместо bash
или csh
за шел на потребителя.
За да го направите, първо трябва да добавите git-shell
към /etc/shells
, ако той вече не е там:
$ cat /etc/shells # проверявате дали git-shell е вече във файла и ако не е...
$ which git-shell # уверете се, че git-shell е инсталиран на системата
$ sudo -e /etc/shells # и добавете пътя до него, който показва командата which
Сега можете да редактирате шела за даден потребител изпълнявайки chsh <username> -s <shell>
:
$ sudo chsh git -s $(which git-shell)
Сега вече git
потребителят може да използва SSH комуникация само за да изтегля и изпраща Git хранилища и няма да има пълноценен шел достъп в машината.
Ако пробвате, ще получите отказ:
$ ssh git@gitserver
fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute access.
Connection to gitserver closed.
В този момент обаче, потребителите все още могат да използват SSH port forwarding за достъп до всеки хост, който git сървърът вижда.
Ако искате да избегнете това, може да редактирате файла authorized_keys
и да добавите следните опции за всеки ключ, който искате да ограничите:
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
Резултатът трябва да изглежда така:
$ cat ~/.ssh/authorized_keys
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4LojG6rs6h
PB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4kYjh6541N
YsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9EzSdfd8AcC
IicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myivO7TCUSBd
LQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPqdAv8JggJ
ICUvax2T9va5 gsg-keypair
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQDEwENNMomTboYI+LJieaAY16qiXiH3wuvENhBG...
Сега мрежовите команди на Git ще работят нормално, но потребителите няма да имат шел достъп.
Както се вижда от изхода на командата, можете също така да направите директория в домашната такава на потребителя git
, което ще специализира малко git-shell
командата.
Например, можете да ограничите наличните Git команди, които сървърът приема или да промените съобщението, които потребителите виждат, ако се опитат да се логнат през SSH.
Изпълнете git help shell
за повече информация за настройване на шела.