Зачем нужен собственный Git-сервер?
GitHub — это замечательный сервис, но, особенно если вы — индивидуальный разработчик или небольшая компания, вы, при работе с GitHub, столкнётесь с некоторыми ограничениями. Одно из них заключается в том, что в бесплатный пакет услуг не входит хостинг приватных репозиториев. За эту возможность придётся заплатить, как минимум, $7 в месяц.
В подобных ситуациях, для того, чтобы обойти ограничения, или если вам нужно контролировать то, что происходит с вашими репозиториями, лучше всего создать собственный Git-сервер. Это, с одной стороны, поможет сэкономить, а с другой — даст полный контроль над сервером. Среди продвинутых пользователей Linux весьма распространена практика использования собственных Git-серверов, размещаемых, можно сказать, бесплатно, на уже используемых ими серверах.
В этом руководстве мы поговорим о двух подходах к управлению кодовой базой с использованием собственного Git-сервера. Первый заключается в использовании обычного Git-сервера, а второй — в применении инструмента с графическим интерфейсом GitLab. В качестве платформы для экспериментов тут используется сервер на полностью пропатченной Ubuntu 14.04 LTS, развёрнутый на VPS.
Использование Git
Здесь мы рассматриваем сценарий, в соответствии с которым у нас имеется удалённый сервер и локальный сервер. Работаем мы периодически то с одним, то с другим.
Для начала установим Git на этих двух машинах. Git можно установить либо из пакета, доступного в репозитории используемого дистрибутива, либо вручную. Тут мы воспользуемся простейшим методом:
sudo apt-get install git-core
Затем добавим пользователя для Git:
sudo useradd git
passwd git
Для того чтобы упростить доступ к удалённому серверу, настроим вход по ssh без пароля.
Создадим ssh-ключи на локальном компьютере:
ssh-keygen -t rsa
Система спросит у вас о том, куда нужно сохранить ключ. Если вас устраивает стандартное место хранения ключа, просто нажмите Enter. Далее вам предложат задать пароль, который будет нужен для доступа к удалённому серверу.
Вышеописанная команда генерирует два ключа — открытый и закрытый. Запишите или запомните расположение открытого ключа. Он понадобится нам на следующем шаге.
Теперь надо скопировать эти ключи на сервер, что даст возможность наладить канал связи между двумя машинами. На локальном компьютере выполните следующую команду:
cat ~/.ssh/id_rsa.pub | ssh git@remote-server "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
Теперь подключитесь по ssh к серверу и создайте директорию проекта для Git. Для репозитория можно использовать любую папку, которая покажется вам подходящей:
git@server:~ $ mkdir -p /home/swapnil/project-1.git
Затем перейдите в эту директорию:
cd /home/swapnil/project-1.git
Создайте пустой репозиторий:
git init --bare
Если команда успешно сработала, вы увидите сообщение, подобное следующему:
Initialized empty Git repository in /home/swapnil/project-1.git
Теперь нужно создать Git-репозиторий на локальной машине. Для этого создаём директорию:
mkdir -p /home/swapnil/git/project
Переходим в неё:
cd /home/swapnil/git/project
Далее, создаём в ней файлы проекта, и, оставаясь в ней, инициализируем репозиторий:
git init
Об успешной инициализации репозитория можно судить по такому сообщению:
Initialized empty Git repository in /home/swapnil/git/project
Теперь добавим файлы проекта в репозиторий:
git add .
С этого момента, после добавления в проект новых файлов или после изменения существующих, нужно будет выполнять вышеописанную команду (
git add .
). Кроме того, нужно будет выполнять команду git commit
, задавая сообщения, описывающие коммиты. Выглядит это примерно так:git commit -m "message" -a
[master (root-commit) 57331ee] message
2 files changed, 2 insertions(+)
create mode 100644 GoT.txt
create mode 100644 writing.txt
В нашем случае здесь имеется файл, который называется GoT (в нём лежит текст обзора Game of Thrones), в который внесены некоторые изменения. Изменения внесены и в другой файл. Поэтому при выполнении команды система сообщила о том, какие изменения были внесены в файлы. В вышеописанной команде опция
-a
означает обработку всех файлов репозитория. Если вы внесли изменения лишь в один файл, можно, вместо опции -a
, указать имя этого файла.Например:
git commit -m "message" GoT.txt
[master e517b10] message
1 file changed, 1 insertion(+)
До сих пор мы работали на локальном сервере. Теперь нам нужно отправить локальные данные на удалённый сервер, что сделает их доступными через интернет и позволит организовать совместную деятельность нескольких разработчиков:
git remote add origin ssh://git@remote-server/repo-<wbr< a="">>path-on-server..git
Теперь можно отправлять изменения с локальной машины на сервер или загружать данные с сервера, используя, соответственно, опции
push
или pull
:git push origin master
Если над проектом намереваются работать и другие программисты, сначала им надо клонировать репозиторий с сервера на своих локальных компьютерах:
git clone git@remote-server:/home/swapnil/project.git
В данной команде
/home/swapnil/project.git
— это путь к папке проекта на удалённом сервере, в вашем случае тут будет другой путь.Затем, после клонирования, надо перейти в директорию проекта:
cd /project
У вас, вместо
project
будет имя другой директории. Теперь можно приступать к работе над проектом, принимать изменения и отправлять их на сервер:git commit -m 'corrections in GoT.txt story' -a
git push origin master
Мы полагаем, что вышеприведённых сведений достаточно для того, чтобы помочь тем, у кого не было опыта работы с Git, приступить к использованию собственного Git-сервера. Если вам нужен некий инструмент с графическим интерфейсом, позволяющий работать с проектом на локальной машине, можно воспользоваться чем-то вроде QGit или GitK для Linux.
QGit — графический инструмент для локальной работы с Git-репозиториями
Использование GitLab
Выше мы описали систему, позволяющую организовать совместную работу над проектами с помощью Git, полностью основанную на средствах командной строки. Работать в такой среде, конечно, сложнее, чем с GitHub. По иронии судьбы, хотя GitHub — это крупнейший в мире сервис для хостинга кода, его собственный код закрыт. Это — не опенсорсный проект, то есть, нельзя взять этот код и создать на его основе собственный GitHub. В отличие от чего-то вроде WordPress и Drupal, код GitHub нельзя загрузить и развернуть на собственном сервере.
Но, как это обычно бывает в мире опенсорса, проектам с закрытым кодом можно найти замену. В данном случае заменой GitHub может послужить весьма привлекательный опенсорсный проект GitLab. Он позволяет всем желающим разворачивать на собственных серверах нечто подобное GitHub. При этом GitLab можно использовать и для поддержки работы крупной компании или большой команды, и для организации собственного репозитория для небольшого проекта, который пока не готов к тому, чтобы представить его широкой общественности.
GitLab задействует бизнес-модель, характерную для опенсорсных проектов. А именно, имеется свободно распространяемая версия ПО, которую все желающие могут разворачивать на своих серверах, и хостинг кода, похожий на GitHub.
Свободно распространяемая версия GitLab имеет две редакции — бесплатную Community Edition (Core) и платную Enterprise Edition (существуют её варианты Starter, Premium и Ultimate). Последняя основана на Community Edition, которая отлично масштабируется, и, кроме того, включает в себя некоторые дополнительные возможности, ориентированные на организации. Это немного напоминает позиционирование WordPress.org и WordPress.com.
Среди возможностей GitLab можно отметить управление Git-репозиториями, средства обзора кода, наличие системы отслеживания ошибок, ленты активности, поддержку вики-страниц. Здесь имеется и GitLab CI — система непрерывной интеграции.
Многие VPS-провайдеры, вроде DigitalOcean, предлагают пользователям дроплеты GitLab. Если вы хотите развернуть GitLab на собственном сервере, вы можете установить эту систему вручную. GitLab предлагает пакет Omnibus для различных операционных систем. Прежде чем установить GitLab, может возникнуть необходимость в настройке почтового SMTP-сервера для того, чтобы система могла отправлять электронную почту. Рекомендовано для этих целей пользоваться Postfix. Поэтому, перед установкой GitLab, установим Postfix:
sudo apt-get install postfix
В процессе установки Postfix система задаст вам несколько вопросов. Не стоит пропускать ответы на них, но если ответы на них не даны, можно перенастроить систему, выполнив следующую команду:
sudo dpkg-reconfigure postfix
После запуска этой команды нужно указать параметр Internet Site и задать почтовый идентификатор для домена, который будет использоваться GitLab. Далее, надо будет указать имя пользователя для Postfix и почтовый адрес. Значения остальных параметров можно не менять. После установки и настройки Postfix можно заняться GitLab.
Загрузим свежий пакет отсюда с помощью
wget
:wget https://downloads-packages.s3.amazonaws.com/ubuntu-14.04/gitlab_7.9.4-omnibus.1-1_amd64.deb
Теперь установим его:
sudo dpkg -i gitlab_7.9.4-omnibus.1-1_amd64.deb
Настроим и запустим GitLab:
sudo gitlab-ctl reconfigure
Теперь надо будет настроить доменное имя в конфигурационном файле, что даст возможность работать с GitLab. Откроем файл:
nano /etc/gitlab/gitlab.rb
В этом файле надо будет отредактировать параметр
external_url
, указав здесь доменное имя сервера. После редактирования файла его надо сохранить, после чего только что созданный GitLab-сайт можно открыть в браузере.Сайт GitLab, открытый в браузере
По умолчанию система создаёт учётную запись администратора с именем
root
и паролем 5iveL!fe
. Сразу после первого входа на сайт следует поменять пароль.Смена пароля на сайте GitLab
После того, как пароль изменён, можно войти на сайт и заняться работой с проектами.
Работа с проектами в GitLab
GitLab — это серьёзная система, имеющая массу возможностей. Как в них разобраться? Позволим себе привести тут несколько изменённую цитату из фильма «Матрица»: «Увы, невозможно рассказать о том, что умеет GitLab. Вы должны увидеть это сами».
Уважаемые читатели! Пользуетесь ли вы собственными Git-серверами? Если да — просим рассказать о том, как вы их настраиваете и поддерживаете.
Комментарии (31)
kvaps
24.05.2018 12:01Одно из них заключается в том, что в бесплатный пакет услуг не входит хостинг приватных репозиториев.
Ну кстати стоит отметить, что Gitlab.com сам по себе бесплатно предлагает хостинг приватных репозиториев.
Sovigod
24.05.2018 12:03+4Я конечно понимаю что это перевод. Но это инструкция по установке версии 7.9.4. Которая вышла в апреле 2015 года. На убунту14.04 срок поддержки которой заканчивается уже через год.
frostspb
24.05.2018 12:20+1Дык еще и файла /etc/gitlab/gitlab.rb давно нет. Его переложили в другое место, в свое время только на стековерфлоу нашел где этот файл лежит.
/opt/gitlab/etc/gitlab.rb.template теперь этот файл
ertaquo
24.05.2018 12:30А можно еще проще…
sudo docker run --detach --hostname gitlab.example.com --publish 443:443 --publish 80:80 --publish 22:22 --name gitlab --restart always --volume /srv/gitlab/config:/etc/gitlab --volume /srv/gitlab/logs:/var/log/gitlab --volume /srv/gitlab/data:/var/opt/gitlab gitlab/gitlab-ce:latest
docs.gitlab.com/omnibus/docker
artiom_n
24.05.2018 13:12Аналогично: использовал gitlab (gogs не устроил по причине отсутствия ревью кода), но в докер-контейнере, что было гораздо проще и удобнее.
Valsha
24.05.2018 13:26Час назад обновил свой инстанс GitLab до актуальной версии 10.8. В версии 10.7.4 они ещё сделали бесплатный WebIDE, очень удобно. Так же использую Gogs, но только для зеркалирования чужих репозиториев на свой git, потому как в GitLab зеркалирование доступно в платной версии.
BATAZOR
24.05.2018 15:37+2С версии 10.8 теперь и в CE есть зеркалирование репозиториев
Merifri
24.05.2018 15:48+1К сожалению, в CE есть только push mirroring.
onegreyonewhite
25.05.2018 02:05Я для этого держу репозиторий на gitlab.com и там настроил синхронизацию на локальный. Очень удобно, кстати, и бесплатно.
xRay
24.05.2018 21:36Сравнение Gitea, Gogs, GitHub EE, GitLab CE, GitLab EE, BitBucket docs.gitea.io/en-us/comparison
monah_tuk
27.05.2018 02:18Когда появляются подобные сравнения на сайте одного из решений… Явно что-то будет не так
Godless
24.05.2018 22:25а мне нравится scm-manager. Хоть и с явой, но функционал из коробки то что надо. давно пользуюсь и там не только git)
kuznetsovin
24.05.2018 23:52Свой репозиторий это хорошо, но его надо еще и поддерживать (бэкапы, падения и прочее) сам разворачивал у себя на сервере gogs+droneci, но в итоге вернулся на bitbucket
creker
25.05.2018 01:25Поддерживаю gitlab уже несколько лет. Никаких проблем за все это время не приключилось с ним. Были только мелкие баги, которые в поинт релизах исправляли довольно быстро, либо сразу было временное решение. Вроде проблем при миграции на новую версию. Есть комплектная команда для создания бекапа, cron+rsync и дело в шляпе. Восстановление тоже как по-маслу из бекапов, когда сам накосячил как-то раз.
maxvape
25.05.2018 12:02Сам использую gogs+drone тесты погонять, полет нормальный. Чем связка не устроила?
geektimess
25.05.2018 11:32Здравствуйте. Если не затруднит, покажите пример вот этой строчки…
git remote add origin ssh://git@remote-server/repo-<wbr< a="">>path-on-server..git
Как должна выглядеть эта команда, если сервер расположен по адресу 192.168.0.56, папка с репой — /home/dima/repo
Спасибо.
rionnagel
25.05.2018 11:32Использую гитлаб на центосе на hyper-v. Поражаюсь насколько быстро клепаются обновления. Стабильно раз в месяц, но я обновляю чуть ли не по нескольку раз в неделю — новые фичи и фиксы всё появляются и появляются. gitlab-ci тема просто офигенная и невероятно простая в настройке. Если есть кластер с кубернетсом — есть интеграция. Да и сам гитлаб в докере неплохо работает. Инструмент стал незаменим, особенно автотесты кода puppet и ansible.
maxvape
25.05.2018 11:32Gitlab — хорошо, только его рядом с чем-нибудь, на уже используемый сервер вряд ли поставишь. Вот Gogs, Gitea — эти да, легко, а гитлабу надо свою железяку и не самую слабую, иначе по минуте ждать ответа от сервера.
erley
25.05.2018 15:38Для себя использую обычный gitweb написаный на perl и идущий вместе с git, прикрутил его к nginx. Всё легко и просто, для просмотра репозиториев вполне хватает.
Можно ещё CGit использовать, он полегче и почти так же устанавливается.
Комбайны всякие не люблю, должен быть здоровый минимализм и удобство в работе, а не куча рюшечек.maxvape
25.05.2018 15:59Так просмотреть можно и с помощью git log. Разграничение доступа к репозиториям, управление репозиториями, вебхуки и CI — тут уже gitweb ничем не поможет.
erley
25.05.2018 19:13Это всё понятно.
Но если просто «для себя», то аутентификации от nginx + https вполне достаточно.
Обычно ведь хочется что-то быстро подсмотреть не делая git clone, тут как раз web-интерфейс вполне годится.
А работать с git нужно конечно же из консоли (ну или из IDE какой-нибудь).
Так что незачем огород лишний городить.
geektimess
26.05.2018 04:12Скажите, а где на сервере хранятся файлы? Как их можно посмотреть?
И как сделать, чтоб можно было посмотреть файлы через веб (как на github.com)?
Спасибо.
KYuri
Не всем нужен «нафаршированный» GitLab.
Мне очень нравится легковесный и простой Gogs.
kvaps
Вау, да этож просто клон гитхаба и под MIT!
saboteur_kiev
gitolite еще есть.
denvist
Тогда уж и про Gitea можно упомянуть, так как она является форком Gogs-а и активно разрабатывается.
qRoC
Вместо Gogs советую Gitea, т.к. автор первого добавляет фичи которые подходят ему, а не сообществу.
По этому поводу много возмущений, но их Вы не найдёте — автор постоянно удаляет такие комментарии(и все упоминания Gitea тоже).