Создаём Git сервер своими руками

Автор: | 31.10.2016

sozdayom-git-server-svoimi-rukamiДоброго времени суток, друзья! :-)

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

Вместо этого я вам расскажу о своём опыте создания Git сервера: зачем мне это было нужно, какие варианты рассматривались и как всё, собственно говоря, происходило.

Сразу скажу, что цель была достигнута, но далеко не с первой попытки, как не хотелось бы. Но, обо всё по порядку…

Зачем мне понадобился Git сервер

Для начала позволю себе немного предыстории, откуда у меня появилась идея сегодняшнего разговора.

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

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

Да и механизм автоматических бэкапов проекта, которым системы контроля версий обладают, что называется, «из коробки» никогда лишней не будет, позволяя разгрузить жёсткие диски локальных компьютеров и головы разработчиков :-)

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

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

Так что судьба данной статьи полностью в ваших руках! Жду комментариев 😉

Пока же вернёмся к нашему сегодняшнему разговору.

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

Из всех существующих решений мы выбрали, как ни странно, самое востребованное и прогрессивное на сегодняшний день – распределённую систему контроля версий Git.

Т.е. задача заключалось в создании на одной из машин в нашей локальной сети Git-репозитория (хранилища) проекта, к которому бы имели доступ разработчики, и могли бы читать и записывать в него свои правки.

Судя по описанию, вроде бы ничего сложного, т.к. суть процесса, а также его этапы предельно ясны.

Но когда я приступил к реализации задуманного, выяснилось, что в сети нет ни одного рабочего мануала, который бы описывал все необходимые действия.

К тому же, все найденные мною статьи по теме были крайне устаревшими, т.е. в них участвовали старые версии ПО.

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

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

Но, как только дело доходило до практических действий, то выяснялось, что авторы все, как один, забывали упомянуть о каких-то мелочах, которые не позволяли серверу работать должным образом.

В итоге, работа была сделана, но для этого мне потребовалось потратить целый рабочий день.

Поэтому я и решил с вами поделиться своим опытом и составить полноценный рабочий мануал, который позволит вам в будущем сделать требуемые действия максимально быстро и комфортно, не собирая свою инструкцию по кусочкам, как это делал я :-)

На этом вступительная часть подходит к концу, и мы переходим непосредственно к обзору Git серверов.

Разновидности Git серверов

Как вы поняли, Git сервер – компьютер с Git репозиторием, к которому имеют доступ разработчики.

Следовательно, он может быть расположен как в локальной сети, так и на каком-либо внешнем ресурсе, например, на хостинге.

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

Второй способ с Git сервером во внешней сети более комфортный для работы, потому что можно будет работать с репозиторием не только на работе, но и из дома, кафе или с места отдыха. Главное, чтобы было соединение с Интернетом.

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

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

Думаю, как только она появится в виде срочных правок, в том числе и во внерабочее время, мы этим займёмся, и о процессе я вам обязательно отпишусь :-)

Теперь поговорим о железе, точнее, ОСях.

К счастью, Git-клиент и прочие программы, необходимые для разворачивания сервера, есть для всех распространённых сегодня операционных систем (Windows, Linux, MacOS), так что на серверной машине может быть установлена любая из них. Равно как нет ограничений и для рабочих станций.

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

Установка и конфигурация Git сервера

Раз уж мы начали говорить об ОС, то пару слов о решениях, которые были установлены на машинах, принимающих участие в эксперименте.

В моём случае на компьютеры разработчиков работали под Windows 10 Professional, а для сервера был выбран дистрибутив Linux – Ubuntu самой последней на текущий момент версии 16.06.

Так что, как видите, ОСи мы использовали самые свежие. Но, для предыдущих версий процесс установки Git сервера особо отличаться не будет, поэтому если вы являетесь обладателем таковых, то расстраиваться не стоит.

Переходим непосредственно к описанию рабочего процесса. Начнём с действий на стороне сервера.

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

На сервере у меня установлен Ubuntu, поэтому заходим в консоль и прописываем следующее:


sudo apt-get update

sudo apt-get install git

Данные команды позволят вам автоматически скачать из пакетного репозитория и установить на компьютер, работающий под Linux, самую последнюю версию Git.

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

Если у вас на сервере будет установлена другая ОС, то для них вы можете скачать дистрибутивы с официального сайта Git — https://git-scm.com/downloads. На данный момент доступны решения для Mac OS X, Linux (включая его дистрибутивы – Ubuntu, Debian, Arch Linux и т.д.), а также Windows.

Шаг 2. Следующим шагом будет создание системного пользователя для работы с Git. В моём случае он так и будет назваться – git. Прописываем следующую команду:


sudo adduser git

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

Шаг 3. Теперь создаём сам репозиторий. Для этого сначала переключаемся на нашего только что созданного пользователя:


su git

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


cd /home/git

Шаг 4. И создаём так bare-репозиторий, т.е. чистый, не содержащий каких-либо файлов. По стандарту Git каталоги таких репозиториев должны содержать в названии окончание «.git»:


mkdir myrepo.git

Заходим в каталог и инициализируем в нём наш bare-репозиторий:


cd /home/git/myrepo.git

git init --bare

Всё, наш репозиторий готов. Теперь перед нами будет стоять задача организации связи между сервером и клиентом, чтобы мы могли производить чтение/запись данных в репозиторий.

Шаг 5. Узнайте IP-адреса компьютеров, включённых в одну локальную сеть с вашим сервером с помощью команды, которую нужно вводить в консоли на сервере:


nmap –sP 192.168.1.0/24

Если система выдаст ошибку, ссылаясь на несуществующую команду, то нужно будет предварительно установить nmap следующей командой:


sudo apt-get install nmap

По идее, если nmap вернёт вам список хостов с подробной информацией о них (их локальные IP-адреса, время ответа компьютера и т.д.), то это уже будет значить, что связь между сервером и рабочими станциями присутствует.

Если же вам этого покажется мало, то можете попробовать пропинговать какую-то конкретную станцию по её IP-адресу, который вы узнали с помощью предыдущей команды:


ping 192.168.1.101

Думаю, и так понятно, что здесь вместо примера нужно указать реальный IP-адрес рабочей станции.

Если же вам не удалось определить IP компьютеров изложенными выше способами, то, скорее всего, что в сети существуют какие-то проблемы. Попробуйте проверить, включены ли компьютеры в сеть (наличие вставленного сетевого кабеля) и настройки подключения на вервере и рабочих станциях.

Также могут быть какие-то проблемы с сетевым оборудованием, которое связывает ваши ПК (роутер, свич, маршрутизатор и т.д.).

Итак, мы убедились в том, что физическая связь между сервером и рабочими станциями присутствует. Теперь нужно настроить передачу данных между ними.

Тут следует сказать, что связь между двумя Git-репозиториями может осуществляться несколькими способами, с помощью различных сетевых протоколов:

  • локальный;
  • HTTP;
  • SSH;
  • Git.

Я не буду сейчас заниматься обзором особенностей каждого приведённого протокола, а также плюсов и минусов его использования. Тем более, что об этом замечательно написано на официальном сайте Git — https://git-scm.com/book/ru/v2/Git-на-сервере-Протоколы.

Если хотите – почитайте на досуге :-)

Скажу только, что для своей ситуации я выбрал SSH-протокол благодаря возможности производить как чтение данных, так и запись, причём, предварительно зашифровав их и сжав.

Также этот протокол обеспечивает безопасность операций с данными, т.к. они производятся по авторизованным каналам.

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

А поскольку, как я раньше говорил, такая возможность не исключается, то я решил настраивать Git сервер с заделом на будущее.

Также в пользу SSH-протокола хочу добавить, что он поддерживается большинством современных хостинг-провайдеров. Следовательно, если вы захотите развернуть Git сервер на хостинге, то SSH – то, что вам нужно, и дальнейшие настройки соединения будут актуальны также и для вашего случая.

6. Итак, при передаче данных по SSH, как и в случае других протоколов, у нас есть сервер и клиент. В нашем случае сервером будет выступать, как ни странно, машина, на которой расположен главный Git-репозиторий.

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

Я использовал наиболее распространённый продукт – OpenSSH, который устанавливается аналогичным Git-у способом:


sudo apt-get update

sudo apt-get install ssh

По идее, в Ubuntu он должен быть установлен по умолчанию, но то ли мне дистрибутив ОС такой попался, то ли его у меня просто не было.

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

Да и вообще странное было дело: в мануалах рекомендовали править файл authorized_keys, о котором мы ещё поговорим, а в каких конфигах прописывать использование этого файла — не указывалось.

Может быть, файл должен был подхватываться по умолчанию, но у меня этого не происходило до момента, пока я не установил OpenSSH и не настроил его.

На этом этапе сервер полностью настроен. Мы ещё будем на него заходить, но пока перенесём наши действия на сторону клиента:

Шаг 1. Прежде всего, как и на сервере, устанавливаем Git. Я уже говорил, что на клиентских машинах у меня была установлена ОС Windows. Следовательно, установка отличалась от Linux – мне нужно было скачать и установить дистрибутив.

После этого в контекстном меню проводника (появляется при клике на каталоге правой кнопкой мыши) у меня появился доступ к Git Bash и Git GUI.

Первый инструмент является аналогом консоли Linux, позволяющий общаться с Git путём специальных команд, перечень которых доступен в официальной документации.

Второй представляет собой графическую оболочку для работы с репозиторием и управления данными в нём.

git-gui-graphicheskaya-obolochka

Я лично пользовался Git Bash, потому что, как по мне, знание Git-команд – это уже неплохой профит, поэтому буду рассказывать о работе с ним.

Шаг 2. Теперь нам нужно сгенерировать SSH-ключ, с помощью которого будет возможна связь с сервером по протоколу SSH. Для его генерации можно воспользоваться Git Bash.

Запускаем его с помощью ярлыка, который должен был появиться после установки Git на ПК, или через контекстное меню какого-либо каталога на компьютере.

И прописываем следующую команду:


ssh-keygen -t rsa -C "ваш_email@domain.com"

Мы вызвали утилиту для генерации SSH-ключей, которая входит в состав Git, и передали в качестве параметров генерации свой email. Если его не указывать, то SSH-ключ будет ассоциироваться с именем рабочей станции.

Также утилита предлагает указать файл, в который будет сохранён SSH-ключ, и задать пароль, который будет учитываться при генерации. Для простоты я оставил файл по умолчанию, нажав Enter, а пароль пустым, нажав на ту же клавишу ещё два раза.

В результате получился такой ключ:

generaciya-ssh-klyucha-git-ssh-keygenШаг 3. Теперь, когда у вас есть SSH-ключ, осталось только его скопировать и отправить вашему системному администратору, чтобы он разместил его на сервере.

Самый простой способ – это скопировать ключ прямо из консоли Git Bash путём выделения ключа и нажатии клавиш «Ctrl+Insert» для создании его копии в буфере обмена.

После осталось только вставить его в письмо и отправить администратору по почте, через Skype или другим удобным для вас способом.

Можно также отправить файл с SSH-ключом, который по умолчанию хранится в каталоге .ssh, находящемся в домашней папке пользователя. В ОС Windows она хранится по пути C:\Users\Имя пользователя\.ssh, в Linux-базированных системах же её можно отыскать в /home/имя_пользователя/.ssh.

Обратите внимание! Папка может быть скрытой, поэтому для того, чтобы её увидеть, вам необходимо будет включить режим отображения скрытых файлов и папок в вашей ОС.

После генерации ключа посредством ssh-keygen в .ssh должны быть два файла – id_rsa и id_rsa.pub. Нам нужен будет с расширением .pub, который необходимо будет отправить системному администратору для размещения на сервере.

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

Шаг 1. Указывать SSH-серверу ключи клиентов будем с помощью файла authorized_keys, который необходимо будет создать в каталоге .ssh в домашней папке пользователя для работы с Git.

Заходим в каталог и создаём там файл:


su git

mkdir ~/.ssh

cd ~/.ssh

touch authorized_keys

Шаг 2. Теперь нам в него нужно будет скопировать содержимое pub-файла, который содержит SSH-ключ, либо вставить в конец authorized_keys ключ, присланный по почте в явном виде.

Рассмотрю пример с копированием содержимого файла. Допустим, файл лежит в папке /tmp:


cat /tmp/id_rsa.pub >> ~/.ssh/authorized_keys

Шаг 3. Конфигурируем OpenSSH на использование SSH-ключей доступа из файла authorized_keys. Для этого нам нужно будет отредактировать файл его настроек:


sudo mcedit /etc/ssh/sshd_config

В качестве текстового редактора я использовал mcedit, у вас может быть другой.

Ищем в нём строку AuthorizedKeysFile .ssh/authorized_keys и раскомментируем её, если в её начале присутствует символ «#».

Шаг 4. Перезапускаем (restart) или стартуем OpenSSH, если он до сих пор не был запущен от рутового пользователя:


sudo service ssh start

На этом с сервером мы заканчиваем, т.к. все необходимые действия уже произведены. Теперь нам осталось записать данные на Git удалённый сервер с клиентских машин, чем мы и займёмся.

Шаг 1. Поскольку SSH-соединение между сервером и нашей рабочей станцией должно быть уже установлено, то будет не лишним ещё раз в этом убедиться.

Для этого нужно воспользоваться любым SSH-клиентом. Поскольку, напомню, у меня на компьютерах разработчиков установлена ОС Windows, то мой выбор пал на популярную утилиту PuTTY, которую можно скачать с сайта её создателя — http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Здесь, кстати, вы сможете установить как весь набор инструментов пакета PuTTY, так и скачать их по отдельности. Рекомендую всё же скачать пакет полностью и установить все компоненты. Для этого нужно загрузить инсталлятор и запустить его.

После установки на рабочем столе должен появиться ярлык PuTTY, который будет ссылаться на SSH-клиент, входящий в данный набор.

Запускаем его и в поле «Имя хоста или IP-адрес» вводим локальный IP-адрес нашего Git сервера. Порт оставляем тот, который прописан по умолчанию – 22:

test-ssh-soedineniya-s-pomoschyu-putty

Нажимаем «Open» для открытия соединения. Предварительно можно ввести имя соединения и нажать «Save», если вам нужно будет сохранить настройки для дальнейших подключений. Потом нужно будет дважды кликнуть на требуемом соединении левой кнопкой мыши.

После этого, при наличии связи с указанным сервером, откроется консоль с предложением ввести имя пользователя (git в нашем случае) и его пароль, который мы задавали ему на сервере при создании.

При успешном вводе данных вы будете авторизованы на сервере под учётной записью пользователя и сможете производить там все необходимые действия.

Кстати, в комплект PuTTY также входит генератор SSH-ключей, которым вы можете пользоваться в качестве альтернативы Git-генератору SSH. В качестве интересных особенностей данного софта есть возможность генерации SSH-файлов в PuTTY-формате, которые используются для работы в различных Git-клиентах.

Также в PuTTYgen (а именно так называется SSH-генератор PuTTY) есть возможность формирования ключей собственного формата из существующих в текстовом виде.

Я не буду сейчас рассказывать, как им пользоваться. Оставлю этот разговор на будущее, если решусь на написание статьи с обзором популярных Git-клиентов. Решиться, кстати, можете помочь мне именно вы, оставив свой отзыв в комментариях под статьёй.

Итак, продолжаем.

Шаг 2. На момент разворачивания Git сервера лично у меня на рабочей станции уже были проекты, которые нужно было залить в серверный репозиторий.

Чтобы это сделать, я зашёл в папку со своим проектом и вызвал Git Bash через контекстное меню каталога. Аналогичного результата можно было добиться запустив Git Bash с рабочего стола и переместиться в каталог  помощью команды cd.

В консоли я прописал следующее:


git init

git add .

Данными командами я инициализировал Git-репозиторий в своём каталоге и добавил в него текущее состояние файлов и папок.

Шаг 3. Теперь нам нужно инициализировать удалённый репозиторий, который будет являться копией нашего локального проекта, с помощью команды:


git remote add origin git@192.168.1.111:/home/git/myrepo.git

Здесь, как не сложно догадаться, нужно указать имя пользователя на сервере (у нас git), имя домена (понадобится при синхронизации с Git сервером на хостинге) или его IP-адрес и путь к репозиторию на сервере.

Всё, теперь нужно создать запись в репозиторий (коммит — commit) и передать её на сервер («запушить» – от названия ответственной команды «push»):


git commit -m 'Первый коммит'

git push origin master

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

Теперь работа с Git сервером будет осуществляться по такой схеме:

  • изменения из главного репозитория копируются на локальный компьютер (текущие правки, не совпадающие с кодом на Git сервере перезаписаны не будут);
  • фиксируем свои исправления;
  • создаём коммит;
  • заливаем всё на сервер.

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


git pull origin master

git add --all

git commit -m ‘Новый коммит’

git push origin master

Запись и чтение в этом примере происходит в ветку master нашего репозитория. Естественно, что при наличии нескольких разработчиков на одном проекте, возникнет необходимость создавать, как минимум, каждому свою ветку, если не пойти дальше и не делать отдельную для каждой задачи.

Поэтому придётся к данному перечню часто используемых команд для работы с Git добавить ещё две комманды:


git checkout developer1

git merge master

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

Как вы могли заметить, полученная нами в итоге модель Git сервера предполагает наличие в коллективе разработчиков, которые будут заниматься работой с копией проекта у себя на локальных компьютерах с последующей фиксацией изменений на сервере, и администратора, который будет заниматься добавлением новых репозиториев на сервере и SSH-ключей пользователей для работы с ними.

Когда в вашей команде появится новый человек, которому нужно будет развернуть копию проекта на его локальной машине, то ему достаточно будет установить Git, сгенерировать SSH-ключ и передать его администратору.

Для получения локальной копии репозитория ему достаточно будет выполнить всего одну команду в Git Bash:


git clone git@192.168.1.111:/home/git/myrepo.git

Естественно, прописав свои значения имени пользователя, адреса сервера и пути к репозиторию на сервере.

Напоследок хотелось бы сказать пару слов о том, как менять адрес или алиас Git удаленного репозитория.

У меня, к примеру иногда возникает такая ситуация на работе, когда при неполадках с сетью сбрасывается IP-адрес Git удалённого сервера.

Тогда закоммититься невозможно, т.к. меняется адрес репозитория целиком. Что же нужно делать?

Во-первых, идем к серверу и узнаем его новый IP-адрес путем прописывания в консоли команды ipconfig, если сервер работает под Windows, или ifconfig, если под Linux.

Если Git сервер находится в одной локальной сети с вами, то, скорее всего, его айпишник будет выглядеть так:


192.168.1.*

Если у вас нет прямого доступа к серверу, то обратитесь к системному администратору, т.к. удаленно узнать IP у вас не получится, т.к. без его знания вы банально не подключитесь к машине.

По крайнем мере, я таких способов не знаю. Если вы в курсе — не жадничайте и поделитесь им в комментариях со всеми :-)

Во-вторых, на локальной машине запускаем Git Bash в директории, для которой инициализирован репозиторий, и вводим команду, чтобы посмотреть список Git удаленных репозиториев, с которыми связан локальный:

git remote -v

Команда вернет результат в таком формате:

origin git@старый_ip_сервера:репозиторий.git (fetch)
origin git@старый_ip_сервера:репозиторий.git (push)

Ну, и в-третьих, копируем адрес, начинающийся с git@…, вводим следующую команду для непосредственной смены адреса и вставляем скопированный адрес, изменив IP на новый:

git remote set-url origin git@новый_ip_сервера:репозиторий.git

Всё, удалённый git репозиторий изменён. Для проверки можно ещё раз вызвать команду

git remote -v

Если все сделали верно, то команда вернёт уже новый адрес репозитория. Кстати, данный метод вам поможет не только при смене IP Git сервера, но и каталога репозитория на сервере.

Удалить удалённый Git репозиторий, к слову, ещё проще, т.к. не нужно вводить адрес целиком, а достаточно одного алиаса:

git remote rm origin (или другое имя удалённого Git репозитория)

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

Надеюсь, что в итоге у вас всё получилось, как и у меня. С нетерпением жду ваших комментариев.

Также не забывайте подписаться на обновления проекта, т.к. в будущем мы обязательно продолжим сегодняшний разговор и поговорим о различных графических Git-клиентах, делающих процесс работы с репозиториями ещё проще и быстрее, а также о веб-интерфейсах репозиториев на сервере, позволяющих отображать их содержимое и манипулировать существующими проектами.

На этом прощаюсь с вами и до новых встреч! :-)

  1. 5
  2. 4
  3. 3
  4. 2
  5. 1
10 голосов, в среднем: 4.8 из 5

18 комментариев к статье "Создаём Git сервер своими руками"

  1. Марина

    Здравствуйте. Появился вопрос по коддингу, не знала куда написать, а тут пришла ваша рассылка на почту :-) Прошу прощения, что не туда, но не нашла подходящую тему для моего вопроса. Ситуация в следующем: в футере сайта вставили код кнопок соцсетей. Теперь эти же кнопки нужно вставить в сайдбар, но в чистом виде они не отображаются корректно. Подскажите как изменить код, чтобы кнопки нормально отображались. Прошу прощения за такой размер, но очень нужна помощь !

    1. Pashaster Автор

      Добрый вечер! Код я из Вашего комментария вырезал, чтобы он не дай Бог ещё и мне вёрстку на сайте не поломал, и не отпугнул других посетителей своими объёмами :-)

      По поводу Вашей проблемы — тот кусок, который Вы предоставили — это CSS код и, поскольку в футере кнопки отображались корректно, то и в сайдбаре, по идее, с ними всё должно быть ОК. Так что дело, скорее всего, в HTML-разметке.

      В любом случае, нужно смотреть проблему на сайте непосредственно, очень сложно что-то сказать в режиме просмотра фрагментов кода. Да и понятие «Не отображаются корректно» — согласитесь, весьма расплывчатое :-)

      Так что нужно смотреть своими глазами. Попробуйте ещё раз всё внимательно просмотреть и поменять CSS-свойства и местоположение элементов, воспользовавшись инспектором объектов вашего браузера, основы пользования которым указаны в данной статье. Если всё же ничего не получится — обращайтесь — cccpblogcom@gmail.com

  2. Alex

    Подскажите, как сделать доступ к репозиторию через https:// ?

    1. Pashaster Автор

      Добрый день! Для отключения проверки SSL сертификата для конкретного репозитория открываем консоль, переходим в папку проекта и запускаем команду:

      git config http.sslVerify "false"
      
      1. Alex

        А дальше что? 80-й порт к серверу у меня открыт. Нужно ли что-то добавлять в hosts на сервере? Или нужно настраивать виртуальный хост в nginx? Извините если ерунду написал, пытаюсь разобраться.

        1. Pashaster Автор

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

          1. Pashaster Автор

            По данному формату. Какой у Вас адрес хоста и путь к репозиторию на нём?

          2. Alex

            Хост на удаленной машине — mydomain.tld. Путь к репозиторию /home/git/myrepo.git. К серверу проброшены порты 80, 443 и 22.
            Попробовал выполнить git pull с remote — https://mydomain.tld/myrepo.git и получил вот такую ошибку: «server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none».

          3. Pashaster Автор

            Вам, по идее, достаточно было бы просто зайти консоли в папку своего проекта, в котором инициализирован git-репозиторий, и выполнить команды:

            git remote add origin https://mydomain.tld/home/git/myrepo.git
            
            git config http.sslVerify "false"
            
            git pull origin master
            

            Если у Вас уже прописан remote, удалите его и попробуйте описанные команды ещё раз.

  3. Starter

    Спасибо большое за статью! Очень полезно. Хочу узнать, существует ли в природе какое-нибудь приложение GuiClient, которое выполняло бы всё тоже самое что в статье, но только с удобным интерфейсом без заморочек с ключами и прочим, а лишь созданием пользователя (типичные логин пароль)? У нас в команде ведутся работы с 3d моделями и изображениями, не прогеры) Нет времени возится в консоли. Заранее спасибо за ответ!

    1. Pashaster Автор

      Добрый день! Спасибо Вам за отзыв, рад был помочь :-)

      По поводу приложений, позволяющих работать с Git посредством Gui, конечно же такие есть. Для администрирования репозиториев на сервере (добавление, удаление, просмотр репозиториев) есть всем известный Gitlab, который, правда, в моём случае не пошёл — три дня настраивали, таки не установили самостоятельно без админов :-) На текущей работе используется SCM MAnager. Но можно подыскать и бесплатные альтернативы и более легковесные.

      Если говорить о Gui приложениях на клиентской стороне для банального pull/push в репозитории, то это всем известный TortoiseGit под Windows, а для Linux с вариантами можно познакомиться здесь — https://git-scm.com/download/gui/linux

      Или просто использовать стандартный git gui клиент, который доступен после установки Git на клиентскую машину. Для этого просто нажмите ПКМ на каталоге с репозиторием и выберите Git GUI Here, чтобы открыть инструмент.

  4. Роман

    Здравствуйте. Прочтитал много статей про настройку гита на сервере. НО НИГДЕ не разбирали случаи, когда на серве уже есть готовые боевые проекты и по верх них нужно было развернуть гит. Там уже чистый репозиторий не подойдет, т.к. есть рабочие файлы прокта. Соответственно инициализировав в каждом проекте по обычному репозиторию при пуше получаем ошибку «refusing to update checked out branch: refs/heads/master …». Знаю, ее можно обойти с помощью хук… Но сомневаюсь, что это правильный путь, а просто костыль. Как в таком случае организовать работу с проектами через гит?

    1. Pashaster Автор

      Добрый день. На самом деле порядок действий правильный. Я в подобных ситуациях также инициализировал Git репы в готовых проектах и пушился в них с локалки.

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

      Для Git push с игнорированием ошибок и различий состояния можно использовать следующую вариацию команды:

      git push origin имя_ветки --force
      

      Для аналогичного Git pull я пользовался следующей конструкцией:

      git reset --hard HEAD
      git pull
      

      Следовательно, используйте либо pull, либо push в зависимости от того, где данные полнее — на локалке или в удалённом хранилище.

  5. Pablo

    Доброго времени суток! Спасибо за статью) Вы дали ссылку в одном из комментариев на git приложения на клиентской части, а можете что-то подсказать для серверной части под LINUX тоже с gui интерфейсом для локальной сети, чтоб было не сложно поставить без доступа в интернет.
    Cпасибо!

    1. Pashaster Автор

      Добрый день! Спасибо за отзыв :-)

      По поводу клиентских GUI приложений для Git под Linux — самое простое, как я и говорил, это родной Git Gui клиент.

      Установка на Ubuntu:

      sudo apt-get update
      sudo apt-get install git-gui
      

      Запуск:

      git citool
      

      Если захотите попробовать что-то другое, то вот хороший обзор Git Gui клиентов под Linux — https://git-scm.com/download/gui/linux

      На этой же странице с помощью фильтров сможете подобрать подходящий для Windows, Anroid, Mac и др.

      1. Pablo

        Не много наверно не корректно изъяснил проблему, нужен именно GUI для сервера, не для клиента под Linux, а именно для сервера на Linux. Вы писали про SCM maneger и GITLAB и написали, что если поискать, то можно найти что-то попроще, вот хотел узнать, может что-то есть попроще? Как Вы написали бесплатные и легковесные? Спасибо, за быстрый ответ) А статья и правда очень хорошая))

        1. Pashaster Автор

          Да нет, проблему Вы вполне понятно изъяснили. Это просто я невнимательно прочитал :-)

          По поводу серверных GUI Git аппликух — я лично на прошлой работе использовал для администрирования Git сервера GitList — http://gitlist.org/ Проект оперсорс, код доступен на GitHub — https://github.com/klaussilveira/gitlist

          Правда, он не позволяет создавать и удалять репозитории, только просматривать содержимое и коммиты. Хотя, может, эту фичу уже доработали.

          Ещё можно попробовать эти альтернативы — https://alternativeto.net/software/gitlab/, но сам их не тестил. Остановился на GitList.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *