Git gogs как работать

Gogs: легковесный git-сервис

В числе самых обсуждаемых последних новостей в сообществе разработчиков были новые тарифы GitHub (см., например, здесь).

Конечно, у новых тарифов есть свои преимущества, но с нынешним курсом доллара их вряд ли можно назвать выгодными для российских пользователей.

Некоторые прибегают к альтернативному решению и разворачивают GitLab (или другой git-сервис) на собственном или арендованном сервере.

Но и у этого решения есть свои подводные камни: GitLab очень требователен к системным ресурсам. Для частных лиц гораздо проще платить 7 долларов в месяц за GitHub, чем арендовать сервер надлежащей конфигурации.

Из сказанного, однако, не следует, что у GitHub на сегодняшний день альтернативы нет. Об одном весьма интересном и перспективном решении мы хотели бы рассказать в этой статье. Знакомьтесь: Gogs. Этот инструмент будет интересен как для индивидуальных разработчиков, так и для небольших компаний.

Общая информация

Gogs — продукт китайских разработчиков. На первый взгляд он почти ничем не отличается от GitHub или BitBucket — это даже по дизайну заметно.
Но при всех внешних сходствах у него есть одно выгодное отличие от существующих аналогов: легковесность.

Gogs написан на Go (собственно, это название представляет собой сокращение от Go Git Service). Из этого факта вытекают серьёзные преимущества: низкие требования к системным ресурсам, минимум зависимостей, простота установки и настройки.

• поддержку протоколов HTTP(s) и SSH;
• поддержку SMTP и LDAP;
• возможность создания как приватных, так и публичных репозиториев;
• интеграцию с социальными сетями (пока что поддерживаются GitHub, Google+, а также китайские сервисы QQ и Weibo);
• возможность работы в связке с сервисами непрерывной интеграции и DevOps-сервисами (подробный список).

В конце 2015 года после более чем полугодового перерыва вышла в свет новая версия продукта. В ней было реализовано множество нововведений, самыми важными из которых являются, конечно же, поддержка пулл-реквестов и возможность создания вики-страниц для проектов.
Дизайн Gogs также был заметно улучшен, а интерфейс перевели на 18 языков, включая русский.

Gogs, GitHub и GitLab

Сравним Gogs с другими инструментами аналогичного плана. Результаты сравнения для наглядности представим в виде таблицы:

Характеристика	Gogs	GitHub	GitLab
Баг-трекер	+	+	+
Поддержка аккаунтов организаций	+	+	+
Wiki	+	+	+
Ревью кода	—	+	+
Сниппеты кода	—	+	+
Веб-хуки	+	+	+
Гит-хуки	+	только в enterprise-версии	только в enterprise-версии
Поддержка LDAP	+	+	+
Синхронизация групп LDAP	—	только в enterprise-версии	только в enterprise-версии

Установка Gogs

Рассмотрим процедуру установки и первичной настройки на примере OC Ubuntu 16.04. В качестве СУБД возьмем привычный MySQL.

$ sudo apt-get update $ sudo apt-get install -y mysql-server 

После этого создайте файл gogs.sql:

$ nano gogs.sql 

Добавьте в него следующие строки:

DROP DATABASE IF EXISTS gogs; CREATE DATABASE IF NOT EXISTS gogs CHARACTER SET utf8 COLLATE utf8_general_ci; 

Сохраните внесённые изменения и выполните:

$ mysql -u root -p [пароль пользователя root]< gogs.sql 

Чтобы уcтановить gogs из исходников, вам понадобятся также системы контроля версий git и mercurial:

$ sudo apt-get install git mercurial 

Далее вам нужно будет установить компилятор Go. Откройте файл /.bashrc и добавьте в него следующие строки:

export GOPATH=/home/git/go export GOROOT=/usr/local/src/go export PATH=$:$GOROOT/bin 

Сохраните изменения и выполните:

$ source ~/.bashrc 

После этого установить компилятор Go:

$ wget https://storage.googleapis.com/golang/go1.4.2.linux-amd64.tar.gz $ tar zxf go1.4.2.linux-amd64.tar.gz $ sudo mv go $GOROOT 

Все необходимые зависимости установлены. Можно устанавливать Gogs:

$ go get -d github.com/gogits/gogs $ cd $GOPATH/src/github.com/gogits/gogs $ go build 

По завершении установки нужно настроить запуск Gogs как службы. Для этого вам потребуется просто добавить в /etc/system/systemd файл gogs.service (шаблон см. здесь) и выполнить после этого следующие команды:.

$ sudo systemctl enable gogs $ sudo systemtctl start gogs 

Если всё сделано правильно, то по завершении установки страница настройки Gogs будет доступна по адресу http:// [IP-адрес сервера]:3000. Вся дальнейшая настройка осуществляется через графический интерфейс; там всё довольно просто и интуитивно понятно. Если вы планируете привязать к серверу с Gogs домен, вам потребуется также установить Nginx и настроить его в качестве обратного прокси (подробнее в официальной документации).

В процедуре установки Gogs ничего сложного нет. Но если вы являетесь пользователем нашего сервиса Vscale (кстати, отличный повод им стать), то всё можно сделать ещё проще: совсем недавно мы добавили в панель управления соответствующий образ. Один клик ― и виртуальная машина с уже установленным и настроенным Gogs создана и готова к использованию:

Как только сервер будет создан, откройте в браузере страницу http://[IP-адрес сервера]. Ничего настраивать дополнительно вам не потребуется: всё уже прописано в шаблоне и готово к работе.
Войдите в Gogs с помощью логина и пароля, полученных при установке.

Gogs в работе

Работать с Gogs просто. Если у вас есть опыт работы с GitHub, то вы без труда во всём разберётесь. Для начинающих пользователей в панели управления приводятся подробные шпаргалки.
Приведём элементраный пример. Создадим через графический интерфейс тестовый репозиторий.
После этого клонируем его на локальную машину:

$ git clone http://[IP-адрес сервера]/root/test.git 

Внесём небольшие изменения в файл README.md:

$ echo 'Test' >> README.md 

Закоммитим внесённые изменения:

$ git add --all && git commit -m "init commit" && git push origin master 

Вам будет предложено ввести логин и пароль пользователя Gogs. После этого коммит будет добавлен в репозиторий. В панели управления всё это выглядит так:

Заключение

Мы попробовали поработать с Gogs – и остались вполне довольны. У продукта китайских разработчиков перспективы есть, и неплохие. За последний год (а в первый раз мы познакомились с Gogs в начале 2015 года) была проделана огромная работа по его усовершенствованию, и мы надеемся, что она будет продолжена в будущем.

Gogs уже сейчас является вполне достойной альтернативой GitHub и GitLab.В плане потребления системных ресурсов он гораздо экономичнее, чем любое из аналогичных решений. Как утверждают разработчики в своём блоге, его можно установить даже на RaspberryPi. Не знаем, как насчёт RaspberryPi, но на виртуальном сервере самой простой конфигурации в Vscale Gogs работает вполне стабильно на небольшом количестве репозиториев. Приглашаем всех попробовать и оценить. Если у вас уже есть опыт работы с Gogs — будем рады, если вы поделитесь им в комментариях.

Специально для тех, кто хочет получить готовый настроенный git-сервис, но при этом предпочитает более традиционные и уже зарекомендовавшие себя решения, мы добавили образ с GitLab. Сразу же отметим, что для самых бюджетных и популярных тарифов он недоступен: GitLab потребляет слишком много системных ресурсов, и серверы “младших” конфигураций его просто-напросто не потянут.

Пользуясь случаем, мы хотели бы обсудить ещё одну важную тему. Сегодня некоторые VPS-провайдеры предлагают образы с предустановленным ПО. У нас в Vscale, например, уже есть: Ajenti, VestaCP, WordPress, Docker, GitLab и Gogs. Этот список мы планируем значительно расширить.
В связи с этим — вопрос ко всем пользователям VPS: какие образы с предустановленным ПО вам нужны? Что ещё, помимо стандартных CMS и панелей управления хостингом, вы бы хотели видеть у вашего провайдера? Если в списке чего-то нет, просьба делиться в комментариях.

Как я домашний Git-сервер Gogs на Alpine linux устанавливал

Мне захотелось завести себе домашний Git-сервер, чтобы практиковаться в разработке и развёртывании пет-проектов. Плюс спокойнее, когда твои наработки лежат не только на github.

В качестве операционной системы выбрал Alpine linux, так как меня заинтересовали её возможности. Был опыт размещения на ней небольшого сервиса. Понравилось, что в ней нет ничего лишнего, а ещё она очень лёгкая в плане системных ресурсов.

Исходные данные

В распоряжении был гипервизор на Proxmox 6.1-3, контейнер с системой Alpine просто взял из шаблонов (template) - Alpine Linux 3.12 Kernel 5.3.10-1-pve on an x86_64.

Реализацию Git-сервера выбирал из числа открытых и бесплатных проектов. Решил взять для начала, тот у которого меньше настроек и лишних плюшек. Мне нужен git-сервер, который не требователен к ресурсам и наличием базовых операций. Остановился на проекте Gogs.io.

Причины такого выбора:

1. знакомый интерфейс, т.к. использую на работе;
2. написан на Golang - значит довольно шустрый;
3. минимальный набор настроек и функционала;
4. нормальная документация.

Мой гипервизор пока обладает скромным железом. В распоряжении только:

• ЦПУ - 4 x AMD Ryzen 3 1200 Quad-Core
• ОЗУ - 8 Гб
• Диски - два SSD в ZFS

Из них 1-2 Гб ОЗУ забирает ОС гипервизора. Значит на контейнеры и виртуалки остаётся не так много ресурсов. Решил, что для 1-2 пользователей git-сервера хватит одного ядра, 512 Мб ОЗУ и 8 Гб диска.

Запуск контейнера с ОС Alpine

Настройка и запуск Alpine на Proxmox очень просты и удобны. Описывать их не буду. Скажу только, что мне эта тема с шаблонами очень понравилась. Жаль, что самих шаблонов не так много на мой взгляд.

С другой стороны, никто не мешает развернуть любую ОС и поставить нужный сервис из её пакетов. Например в Alpine так:

alpine:~# apk search zabbix

Подготовка системы

Сменил имя хоста сервера:

alpine:~# hostname gogs-githost

Вначале я установил openssh и nano для его настройки, чтобы нормально подключаться по ssh:

gogs-githost:~# apk add openssh nano

Далее добавил демон в автозагрузку:

gogs-githost:~# rc-update add sshd

Поправил конфиг /etc/ssh/sshd_config и убрал комментарии строк:

. Port 22 … PermitRootLogin yes . 

Всё, запустил демон:

gogs-githost:~# /etc/init.d/sshd start

Установка сервиса Gogs

Попытка первая

В документации к Alpine рекомендуют для разработки использовать Gitea. Но это слишком просто неть, поэтому выбрал другое. Я решил внаглую установить git-сервер командой:

gogs-githost:~# apk add gogs fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/community/x86_64/APKINDEX.tar.gz (1/8) Installing ca-certificates (20191127-r4) (2/8) Installing nghttp2-libs (1.41.0-r0) (3/8) Installing libcurl (7.69.1-r3) (4/8) Installing expat (2.2.9-r1) (5/8) Installing pcre2 (10.35-r0) (6/8) Installing git (2.26.3-r0) (7/8) Installing gogs (0.11.91-r1) Executing gogs-0.11.91-r1.pre-install (8/8) Installing gogs-openrc (0.11.91-r1) Executing busybox-1.31.1-r19.trigger Executing ca-certificates-20191127-r4.trigger OK: 89 MiB in 38 packages

В результате, система помимо самого сервиса gogs установила ещё и дополнительные пакеты, например сам git. Пробую запустить сервер и получаю ошибку:

gogs-githost:~# gogs web 2021/03/18 20:13:42 [ WARN] Custom config '/usr/bin/custom/conf/app.ini' not found, ignore this if you're running first time 2021/03/18 20:13:42 [TRACE] Custom path: /usr/bin/custom 2021/03/18 20:13:42 [TRACE] Log path: /usr/bin/log 2021/03/18 20:13:42 [TRACE] Log Mode: Console (Trace) 2021/03/18 20:13:42 [ INFO] Gogs 0.11.91.0811 2021/03/18 20:13:42 [ INFO] Cache Service Enabled 2021/03/18 20:13:42 [ INFO] Session Service Enabled 2021/03/18 20:13:42 [ INFO] SQLite3 Supported 2021/03/18 20:13:42 [ INFO] Run Mode: Development 2021/03/18 20:13:42 [FATAL] [. gogs/gogs/cmd/web.go:66 checkVersion()] Fail to read 'templates/.VERSION': open /usr/bin/templates/.VERSION: no such file or directory

Как мы видим, ему не хватает конфига и структуры каталогов для работы. Проверил каталог /usr/bin, там оказался лишь одинокий исполняемый файл gogs.

Попытка вторая

После первой попытки я попробовал воссоздать необходимую структуру и конфиг вручную. Ничего хорошего из этого не вышло.

Тогда решил пойти другим путём - в документации Gogs описывается установка под популярные дистрибутивы Linux. Обнаружил там таблицу архивов под две версии Gogs, поэтому проверил, какой установился у меня на Alpine:

gogs-githost:~# gogs -v Gogs version 0.11.91.0811

Решил попробовать вот этот. Скопировал его в директорию /opt на Alpine:

gogs-githost:/opt# wget https://dl.gogs.io/0.11.91/gogs_0.11.91_linux_amd64.tar.gz

gogs-githost:/opt# tar -xvf gogs_0.11.91_linux_amd64.tar.gz

Мой замысел был в том, что либо он заработает после распаковки сразу, либо с него можно будет взять недостающей структуры и конфигов. Поменял права на директорию распакованного gogs:

gogs-githost:/opt# chown -R root:root gogs

Попробовал запустить и получил странную ошибку (спойлер: не удивительно, ведь С-компиляторы разные на Alpine это mysl, но об этом я узнаю позже):

gogs-githost:/opt/gogs# ./gogs web -ash: ./gogs: not found

Тогда то мне и пришла дикая идея подсунуть gogs из Alpine пакетов:

gogs-githost:/opt/gogs# cp /usr/bin/gogs gogs

И бинго! Сервер стартанул и я даже смог его настроить из веб-интерфейса. Но это был не конец…

Попытка третья

Несмотря на охватившую меня эйфорию, радости и “я у мамки сисадмин!” весь следующий день я провёл в раздумьях. Мне не верилось, что в таком перспективном проекте как Alpine, есть место битому пакету. Чувство, что ошибка на моей стороне, не давала покоя.

Я нашел телеграм-чат по Alpine и (увы) на ломаном инглише объяснил свою проблему. Меня направили проверять конфиги в репозитории пакета gogs проекта Alpine.

Честно - у меня не получилось выяснить, в чём ошибка. Но добыл ценную инфу - сервер можно запускать с явным указанием пути к файлу конфига. Попробовал, и штатный gogs-сервер запустился:

gogs-githost:~# gogs web -c /etc/gogs/conf/app.ini 2021/03/20 19:22:47 [TRACE] Custom path: /usr/bin/custom 2021/03/20 19:22:47 [TRACE] Log path: /var/log/gogs 2021/03/20 19:22:47 [TRACE] Log Mode: File (Info) 2021/03/20 19:22:47 [ INFO] Gogs 0.11.91.0811

Дальше настраивал по этому видео-уроку, начиная с момента про настройку из веб-интерфейса.

Конечно, это не полная настройка. При настройке из GUI, я выяснил, что нужно ещё ставить bash.

Кроме этого, нужно настроить автозапуск сервера. Вернее, он уже есть - /etc/init.d/gogs, но не работает:

#!/sbin/openrc-run name=gogs conffile="$GOGS_CUSTOM/conf/app.ini" command="/usr/bin/gogs" command_args="web -c $conffile" start_stop_daemon_args="$ $GOGS_USER --env GOGS_CUSTOM=$GOGS_CUSTOM" pidfile="/var/run/gogs.pid" command_background="yes" depend()

Путём перебора вариантов пришёл к такому:

#!/sbin/openrc-run name=gogs conffile="/etc/gogs/conf/app.ini" command="/usr/bin/gogs" command_args="web -c $conffile" start_stop_daemon_args="$ root --env GOGS_CUSTOM=/etc/gogs" pidfile="/var/run/gogs.pid" command_background="yes" depend()

Грубо, но да - я просто вместо переменных прописал путь и пользователя (того, которого задавал при настройке из веб-интерфейса). Возможно на этот момент мне указывали в чатике Alpine?

Как на самом деле нужно было

После такого долгого пути экспериментов и щупанья головой стены на прочность, меня осенило! Сервер не нужно запускать вручную, он должен стартовать вместе с системой. Значит, его надо настроить по аналогии с openssh.

Снова решил проверить - клонировал контейнер с Alpine и уже настроенным ssh. А дальше всё оказалось очень просто:

alpine:~# apk add gogs alpine:~# rc-update add gogs * service gogs added to runlevel default alpine:~# /etc/init.d/gogs start * Starting gogs . [ ok ] alpine:~# rc-status Runlevel: default networking [ started ] sshd [ started ] crond [ started ] gogs [ started ]

Этого действительно достаточно, чтобы запустить свой Git-сервер (если вас устраивает БД SQLite). Теперь можно идти на веб-интерфейс, у меня это был http://192.168.50.205:3000, и делать базовые настройки.

Заключение

Этой статьёй я хочу обратить внимание на важность документации и навыков по ОС Linux. Скорее всего, опытные линуксоиды сразу поняли в чём дело и от души посмеялись над моим дилетанством. Что ж, теперь мне и самому забавно, каким извилистым был мой путь =).

Но правда также и в том, что простой справки по развороту именно пакета gogs на Alpine я не нашёл. Надеюсь, моя статья будет полезна тем, кто задумает нечто подобное.

Установка Git сервиса Gogs на Linux (Debian 11)

Если требуется установка Git сервиса для индивидуального разработчика или небольшой компании, то легковесный аналог GitLib, который называется Gogs, — это лучшее решение.

Содержание скрыть

Git сервис Gogs

Gogs (GO Git Service) — это сервис Git для установки на собственном сервере, очень похож на GitLib. Gogs написан на языке Go, имеет низкие требования к системным ресурсам (в отличие от GitLib). Прост в установке и настройке. Gogs — лучшее решение, если вам нужен собственный Git репозиторий, и вы не хотите оплачивать тарифы других Git сервисов.

Установка Git сервиса Gogs

Установка Git

Устанавливаем систему контроля версий git:

apt install git

Создание пользователя

Создаем пользователя git:

adduser --disabled-login --gecos 'Gogs' git

Мы создали нового пользователя с именем git и все дальнейшие действия будем выполнять под пользователем git. Чтобы зайти под пользователем git, нужно будет выполнить команду:

su - git

Чтобы завершить работу под пользователем git, нужно будет выполнить команду:

exit

Установка Go

Для компиляции Gogs требуется Go версии 1.18 и новее.

Под пользователем git, которого мы только что создали, создаем новую директорию /home/git/local/:

su - git

mkdir $HOME/local && cd $_

Скачиваем самую новую версию Go. На момент написания статьи это была версия 1.20.2:

wget https://golang.google.cn/dl/go1.20.2.linux-amd64.tar.gz

Распаковываем скаченный архив:

tar -C /home/git/local -xvzf go1.20.2.linux-amd64.tar.gz

Зададим переменную окружения GOROOT, чтобы указать наше локальное место установки Go. Переменные окружения задаем в файле .bashrc. Так переменные окружения будут доступны, когда пользователь входит в систему:

echo 'export GOROOT=$HOME/local/go' >> $HOME/.bashrc

echo 'export GOPATH=$HOME/go' >> $HOME/.bashrc

echo 'export PATH=$PATH:$GOROOT/bin:$GOPATH/bin' >> $HOME/.bashrc

source $HOME/.bashrc

Проверяем установку Go:

go version

Установка Go успешно завершена.

Установка Gogs

Клонируем репозиторий в подкаталог gogs:

git clone --depth 1 https://github.com/gogs/gogs.git gogs

cd gogs

Компилируем Gogs, все необходимые зависимости будут скачены:

go build -o gogs

Проверка работоспособности Gogs

Чтобы проверить работоспособность Gogs, запускаем команду:

./gogs web

Стартовал веб-сервер и случает HTTP соединения на порту 3000. Чтобы остановить веб-сервер, нажмите комбинацию клавиш CRTL+C .

Завершаем работу под пользователем git:

exit

Добавление Gogs в автозагрузку

Настроим автоматическую загрузку Git сервиса Gogs при запуске системы.

Создаем файл /etc/systemd/system/gogs.service:

touch /etc/systemd/system/gogs.service

Добавляем в созданный файл следующее содержимое (проверив пути WorkingDirectory и ExecStart):

[Unit] Description=Gogs After=syslog.target After=network.target After=postgresql.service After=nginx.service [Service] Type=simple User=git Group=git WorkingDirectory=/home/git/local/gogs ExecStart=/home/git/local/gogs/gogs web Restart=always Environment=USER=git HOME=/home/git [Install] WantedBy=multi-user.target

Активируем созданный нами systemd файл:

systemctl enable gogs

systemctl start gogs

Проверяем статус сервиса:

systemctl status gogs

Все отлично запустилось и работает! Можно перезагрузить сервер и проверить, что Git сервис Gogs автоматически запускается.

Установка PostgreSQL

Gogs не требует обязательное использование сервера баз данных. Поэтому, можете пропустить данный подраздел, если не планируете использовать Gogs вместе с сервером баз данных.

Устанавливаем необходимые пакеты:

apt install postgresql postgresql-client libpq-dev

Открываем PostgreSQL-терминал, чтобы создать базу данных и пользователя для Gogs:

sudo -u postgres psql -d template1

Создаем нового пользователя с именем gogs:

CREATE USER gogs CREATEDB;

Задаем пароль для пользователя gogs:

\password gogs

Будет предложено ввести новый пароль для пользователя gogs, а затем повторить его ввод.

Создаем базу данных gogs, владельцем которой будет пользователь gogs:

CREATE DATABASE gogs OWNER gogs;

Выходим из PostgreSQL-терминала:

Установка и настройка Nginx

Установим и настроим Nginx в качестве обратного прокси-сервера для Gogs. Благодаря этому, сможем получать доступ к Gogs не по IP адресу сервера, где располагается Gogs, а используя доменное имя (git.adminkin.com). Nginx также будет обрабатывать HTTPS соединения к Gogs.

apt install nginx

Создаем конфигурационный файл /etc/nginx/sites-available/git.adminkin.com.conf:

touch /etc/nginx/sites-available/git.adminkin.com.conf

Добавляем в файл следующие строки:

server < listen 80; server_name git.adminkin.com; root /var/www/html; index index.nginx-debian.html; location / < try_files $uri $uri/ =404; >> 

Создаем символьную ссылку:

ln -s /etc/nginx/sites-available/git.adminkin.com.conf /etc/nginx/sites-enabled/git.adminkin.com.conf

nginx

Ура! Домен git.adminkin.com доступен по HTTP на 80 порту:

Пора получать бесплатный SSL сертификат от Let’s Encrypt на домен git.adminkin.com. Устанавливаем Certbot (клиент Let’s Encrypt, который создает и устанавливает SSL сертификаты от Let’s Encrypt):

apt install certbot python3-certbot-nginx

Запускаем Certbot для генерации SSL сертификата и его установки на сайт:

certbot --nginx -d git.adminkin.com -d www.git.adminkin.com --register-unsafely-without-email

Если просмотреть конфигурационный файл /etc/nginx/sites-available/git.adminkin.com.conf, то обнаружите, что Certbot внес изменения в этот файл. Перезагружаем Nginx, чтобы изменения в конфигурационном файле были применены:

nginx -s reload

SSL сертификат работает. Переадресация (редирект) с HTTP на HTTPS, прописанная Certbot-ом в конфигурационном файле, работает.

Для автоматического обновления SSL сертификата добавим задачу в cron. Для этого под пользователем root откроем для редактирования файл crontab:

crontab -e

И добавим следующую строчку:

30 2 * * 1 /usr/bin/certbot renew >> /var/log/certbot.log

Так, каждый понедельник в 2:30 ночи будет запускаться проверка валидности SSL сертификата. Если срок действия SSL сертификата истекает, то сертификат будет обновлен.

Настроим Nginx в качестве обратного прокси-сервера для Gogs. Открываем конфигурационный файл /etc/nginx/sites-available/git.adminkin.com.conf и приводим его к виду:

server < listen 443 ssl; server_name git.adminkin.com; location / < proxy_set_header X-Real-IP $remote_addr; proxy_pass http://localhost:3000; >ssl_certificate /etc/letsencrypt/live/git.adminkin.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/git.adminkin.com/privkey.pem; include /etc/letsencrypt/options-ssl-nginx.conf; ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; > server < listen 80; server_name git.adminkin.com www.git.adminkin.com; return 301 https://$server_name$request_uri; >server < listen 443; server_name www.git.adminkin.com; ssl_certificate /etc/letsencrypt/live/git.adminkin.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/git.adminkin.com/privkey.pem; include /etc/letsencrypt/options-ssl-nginx.conf; ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; return 301 https://git.adminkin.com$request_uri; >

Перезагружаем Nginx, чтобы изменения в конфигурационном файле были применены:

nginx -s reload

Набираем в адресной строке браузера http://git.adminkin.com/, и происходит редирект на https://git.adminkin.com/install. Установка Git сервиса Gogs продолжится в браузере.

Настройка Git сервиса Gogs

Настройки базы данных (см. рисунок выше) оставляем по умолчанию. Вводим только Пароль пользователя gogs базы данных PostgreSQL, который задали в разделе Установка PostgreSQL.

Общие параметры Gogs тоже оставляем по умолчанию, кроме:

• Домен меняем с localhost на git.adminkin.com
• SSH порт делаем пустым полем, т.к. SSH сервер использоваться не будет;
• URL приложения меняем с http://localhost:3000/ на https://git.adminkin.com

Расширенные настройки тоже оставляем по умолчанию. Только создадим учетную запись администратора. Для этого заполняем поля: Имя пользователя, Пароль, Подтвердить пароль и нажимаем кнопку Установить Gogs:

В дальнейшем, если потребуется изменение параметров Gogs, это можно сделать вручную, открыв конфигурационный файл /home/git/local/gogs/custom/conf/app.ini.

Все! Мы оказались в панели управления администратора Gogs, можем создавать свой первый собственный Git-репозиторий (здесь мы этого касаться не будем).

Осталось запретить доступ к сайту Gogs по незащищенному протоколу HTTP. Если в адресной строке браузера набрать http://git.adminkin.com:3000/, то будет предоставлен доступ по HTTP-протоколу:

Это потому, что веб-сервер Gogs прослушивает все сетевые интерфейсы на порту 3000. Для того, чтобы сайт Gogs был доступен только по безопасному HTTPS протоколу, необходимо настроить, чтобы веб-сервер Gogs прослушивал только loopback интерфейс на порту 3000.

Открываем файл /home/git/local/gogs/custom/conf/app.ini с настройками Gogs и в секции [server] добавляем строку:

HTTP_ADDR = 127.0.0.1

Перезапускаем сервис Gogs:

systemctl restart gogs

Проверяем. Доступ по незащищенному HTTP протоколу запрещен:

Выводы

Установка Git сервиса Gogs прошла без проблем. Сам сервис Gogs нетребовательный к ресурсам сервера. Как заявляют его разработчики, может работать на недорогом Raspberry Pi. Gogs — достойная альтернатива GitHub и GitLab.

Как это может помочь бизнесу?

Git сервис Gogs сэкономит деньги бизнеса: не нужно арендовать cервер c супер-конфигурацией (как в случае с GitLab) и не нужно оплачивать все новые и новые тарифы (как в случае с GitHub). Gogs бесплатный, легковесный и кроссплатформенный!

Пожалуйста, вопросы задавайте в комментариях под статьей!

2.1 Основы Git - Создание Git-репозитория

Если вы хотите начать работать с Git, прочитав всего одну главу, то эта глава — то, что вам нужно. Здесь рассмотрены все базовые команды, необходимые вам для решения подавляющего большинства задач, возникающих при работе с Git. После прочтения этой главы вы научитесь настраивать и инициализировать репозиторий, начинать и прекращать контроль версий файлов, а также подготавливать и фиксировать изменения. Мы также продемонстрируем вам, как настроить в Git игнорирование отдельных файлов или их групп, как быстро и просто отменить ошибочные изменения, как просмотреть историю вашего проекта и изменения между отдельными коммитами (commit), а также как отправлять (push) и получать (pull) изменения в/из удалённого (remote) репозитория.

Создание Git-репозитория

Обычно вы получаете репозиторий Git одним из двух способов:

1. Вы можете взять локальный каталог, который в настоящее время не находится под версионным контролем, и превратить его в репозиторий Git, либо
2. Вы можете клонировать существующий репозиторий Git из любого места.

В обоих случаях вы получите готовый к работе Git репозиторий на вашем компьютере.

Создание репозитория в существующем каталоге

Если у вас уже есть проект в каталоге, который не находится под версионным контролем Git, то для начала нужно перейти в него. Если вы не делали этого раньше, то для разных операционных систем это выглядит по-разному:

$ cd /home/user/my_project

$ cd /Users/user/my_project

$ cd C:/Users/user/my_project

а затем выполните команду:

$ git init

Эта команда создаёт в текущем каталоге новый подкаталог с именем .git , содержащий все необходимые файлы репозитория — структуру Git репозитория. На этом этапе ваш проект ещё не находится под версионным контролем. Подробное описание файлов, содержащихся в только что созданном вами каталоге .git , приведено в главе Git изнутри

Если вы хотите добавить под версионный контроль существующие файлы (в отличие от пустого каталога), вам стоит добавить их в индекс и осуществить первый коммит изменений. Добиться этого вы сможете запустив команду git add несколько раз, указав индексируемые файлы, а затем выполнив git commit :

$ git add *.c $ git add LICENSE $ git commit -m 'Initial project version'

Мы разберем, что делают эти команды чуть позже. Теперь у вас есть Git-репозиторий с отслеживаемыми файлами и начальным коммитом.

Клонирование существующего репозитория

Для получения копии существующего Git-репозитория, например, проекта, в который вы хотите внести свой вклад, необходимо использовать команду git clone . Если вы знакомы с другими системами контроля версий, такими как Subversion, то заметите, что команда называется «clone», а не «checkout». Это важное различие — вместо того, чтобы просто получить рабочую копию, Git получает копию практически всех данных, которые есть на сервере. При выполнении git clone с сервера забирается (pulled) каждая версия каждого файла из истории проекта. Фактически, если серверный диск выйдет из строя, вы можете использовать любой из клонов на любом из клиентов, для того, чтобы вернуть сервер в то состояние, в котором он находился в момент клонирования (вы можете потерять часть серверных хуков (server-side hooks) и т. п., но все данные, помещённые под версионный контроль, будут сохранены, подробнее об этом смотрите в разделе Установка Git на сервер главы 4).

Клонирование репозитория осуществляется командой git clone . Например, если вы хотите клонировать библиотеку libgit2 , вы можете сделать это следующим образом:

$ git clone https://github.com/libgit2/libgit2

Эта команда создаёт каталог libgit2 , инициализирует в нём подкаталог .git , скачивает все данные для этого репозитория и извлекает рабочую копию последней версии. Если вы перейдёте в только что созданный каталог libgit2 , то увидите в нём файлы проекта, готовые для работы или использования. Для того, чтобы клонировать репозиторий в каталог с именем, отличающимся от libgit2 , необходимо указать желаемое имя, как параметр командной строки:

$ git clone https://github.com/libgit2/libgit2 mylibgit

Эта команда делает всё то же самое, что и предыдущая, только результирующий каталог будет назван mylibgit .

В Git реализовано несколько транспортных протоколов, которые вы можете использовать. В предыдущем примере использовался протокол https:// , вы также можете встретить git:// или user@server:path/to/repo.git , использующий протокол передачи SSH. В разделе Установка Git на сервер главы 4 мы познакомимся со всеми доступными вариантами конфигурации сервера для обеспечения доступа к вашему Git репозиторию, а также рассмотрим их достоинства и недостатки.