что такое сервер git
Как настроить собственный сервер Git
Если вы хотите настроить систему управления версиями для проекта, но предпочитаете не размещать его в сервисе, таком как GitHub, вы можете запустить свой собственный сервер git на VPS, чтобы хранить свой код и действовать как главный репозиторий для всех соавторов.
Зачем запускать собственный сервер?
С учётом того, сколько существует бесплатных поставщиков для размещения Git, таких как GitHub, GitLab и Bitbucket, нет смысла делать это самостоятельно. Но есть несколько ситуаций, когда это действительно нужно.
Во-первых, запуск собственного сервера гораздо более конфиденциальный, особенно если вы работаете над кодом, который не хотите хранить в чужом «облаке». Нельзя сказать, что такие провайдеры, как GitLab, небезопасны, но размещение всего на собственном сервере может дать некоторым людям больше спокойствия.
Кроме того, если вы используете стороннюю службу, существуют ограничения на размер файла, которые могут быть неидеальными. GitHub не поддерживает файлы размером более 100 МБ, что может стать серьёзной проблемой для проектов с большими двоичными файлами. Использование собственного сервера снимает этот предел, если вы можете заплатить за больше места на жёстком диске.
Каким бы ни был ваш случай использования, вы, вероятно, сможете получить большей функций, чем в git без платной подписки. GitLab Community Edition — это бесплатная версия с открытым исходным кодом, которую легко установить на вашем собственном сервере. Это даёт вам все преимущества самостоятельного размещения, а также очень приятный веб-интерфейс и многочисленные инструменты CI/CD. Мы настоятельно рекомендуем вам использовать GitLab, если у вас есть свободное место на сервере. Для него требуется около 3 ГБ ОЗУ. Вы можете прочитать наше руководство по его установке и настройке, чтобы узнать больше.
Но если вам не нужны все навороты и вы просто хотите запустить простой git remote, то продолжайте читать это руководство.
git remote — это просто чей-то ещё репозиторий
Первое, что следует отметить в отношении git, это то, что размещение сервера на самом деле не очень сложно. Git использует модель распределенного контроля версий; ваш локальный клон репозитория вообще не подключается ко всем вашим коллегам, но он подключается к «удалённому», обычно на внешнем центральном сервере или службе. Когда вы push (отправляете изменения) и pull (скачиваете изменения), вы вносите изменения в официальную главную копию remote. Когда ваши коллеги получают данные с remote, они скачивают ваши commit’ы.
Технически вы можете запустить git как полностью децентрализованный сервис. Если бы у вас было два человека, каждый из них получал бы обновления друг от друга. (Отправка в репозитории, не являющиеся серверными, в этой настройке не рекомендуется.) На практике это нецелесообразно, если обе стороны не имеют статических IP-адресов и всегда находятся в сети, поэтому большинство людей выбирают модель сервер-клиент.
Итак, всё, что представляет собой сервер git, – это просто обычный репозиторий, который настроен как главная копия и открыт для Интернета. Настроить на удивление просто. Во-первых, нам нужно создать нового пользователя. Git использует SSH для аутентификации и шифрования всего трафика между серверами и клиентами, поэтому нам понадобится пользователь службы для управления репозиторием.
Затем переключитесь на пользователя git для остальной части настройки:
Вам нужно будет добавить свои SSH-ключи в файл authorized_keys пользователя git:
Управлять доступом таким способом нелегко, так как вам нужно предоставить всем доступ к одному и тому же пользователю службы, что не идеально, или вам нужно будет настроить отдельных пользователей для каждого человека, что также не идеальный вариант. В любом случае коммиты будут отображаться с любым именем пользователя и адресом электронной почты, которые конечный пользователь настроил в своих настройках git.
В любом случае, чтобы создать реальный репозиторий, просто запустите git init в домашнем каталоге пользователя git:
Здесь необходим параметр —bare. Обычно, когда вы клонируете репозиторий, git хранит все файлы, которые он использует для управления версиями, в скрытой папке .git, а также сохраняет пригодную для использования версию там, где находится ваш текущий извлечённый HEAD. Обычно это делает вашу папку репо примерно вдвое больше, чем она была бы без git, хотя она может быть ещё больше, если у вас есть большие двоичные файлы и много изменений с течением времени.
Это всё, что требуется на стороне сервера. Со своего локального компьютера вам нужно будет клонировать репо или добавить новый remote:
URL-адрес начинается с git@, потому что он подключается через SSH как пользователь git.
example.com — это адрес вашего сервера, который можно указать как имя хоста или IP
:repository.git в конце на самом деле является именем пути, а не просто идентификатором. Путь указывается относительно домашнего каталога пользователя git, поэтому, если вы разместили репозиторий в другом месте, то вам нужно указать абсолютный путь.
После того, как вы подключили локальное репо, у вас должен быть полный доступ для push и pull в обычном режиме. Имейте в виду, что git по умолчанию не имеет встроенной системы разрешений, поэтому ничто не мешает любому, у кого есть доступ к пользователю git, иметь полный контроль над вашим главным репозиторием.
Создание, настройка и использование собственного Git-сервера
Материал, перевод которого мы сегодня публикуем, посвящён настройке Git-серверов. Git — это система управления версиями, разработанная Линусом Торвальдсом. Git пользуются миллионы людей во всём мире. Компании, вроде GitHub, предлагают службы хостинга кода, основанные на Git. По информации, которую можно найти в различных публикациях, GitHub является крупнейшим сервисом для хостинга IT-проектов. В частности, в 2017-м году сообщество GitHub достигло 24 миллионов разработчиков, которые трудятся над 67 миллионами репозиториев. В наши дни GitHub пользуются абсолютно все — от программистов-одиночек, до крупных организаций. Надо сказать, что даже компания Google перешла на GitHub, закрыв собственный проект схожей направленности.
Зачем нужен собственный Git-сервер?
В подобных ситуациях, для того, чтобы обойти ограничения, или если вам нужно контролировать то, что происходит с вашими репозиториями, лучше всего создать собственный Git-сервер. Это, с одной стороны, поможет сэкономить, а с другой — даст полный контроль над сервером. Среди продвинутых пользователей Linux весьма распространена практика использования собственных Git-серверов, размещаемых, можно сказать, бесплатно, на уже используемых ими серверах.
В этом руководстве мы поговорим о двух подходах к управлению кодовой базой с использованием собственного Git-сервера. Первый заключается в использовании обычного Git-сервера, а второй — в применении инструмента с графическим интерфейсом GitLab. В качестве платформы для экспериментов тут используется сервер на полностью пропатченной Ubuntu 14.04 LTS, развёрнутый на VPS.
Использование Git
Здесь мы рассматриваем сценарий, в соответствии с которым у нас имеется удалённый сервер и локальный сервер. Работаем мы периодически то с одним, то с другим.
Для начала установим Git на этих двух машинах. Git можно установить либо из пакета, доступного в репозитории используемого дистрибутива, либо вручную. Тут мы воспользуемся простейшим методом:
Затем добавим пользователя для Git:
Для того чтобы упростить доступ к удалённому серверу, настроим вход по ssh без пароля.
Создадим ssh-ключи на локальном компьютере:
Система спросит у вас о том, куда нужно сохранить ключ. Если вас устраивает стандартное место хранения ключа, просто нажмите Enter. Далее вам предложат задать пароль, который будет нужен для доступа к удалённому серверу.
Вышеописанная команда генерирует два ключа — открытый и закрытый. Запишите или запомните расположение открытого ключа. Он понадобится нам на следующем шаге.
Теперь надо скопировать эти ключи на сервер, что даст возможность наладить канал связи между двумя машинами. На локальном компьютере выполните следующую команду:
Теперь подключитесь по ssh к серверу и создайте директорию проекта для Git. Для репозитория можно использовать любую папку, которая покажется вам подходящей:
Затем перейдите в эту директорию:
Создайте пустой репозиторий:
Если команда успешно сработала, вы увидите сообщение, подобное следующему:
Теперь нужно создать Git-репозиторий на локальной машине. Для этого создаём директорию:
Далее, создаём в ней файлы проекта, и, оставаясь в ней, инициализируем репозиторий:
Об успешной инициализации репозитория можно судить по такому сообщению:
Теперь добавим файлы проекта в репозиторий:
До сих пор мы работали на локальном сервере. Теперь нам нужно отправить локальные данные на удалённый сервер, что сделает их доступными через интернет и позволит организовать совместную деятельность нескольких разработчиков:
Теперь можно отправлять изменения с локальной машины на сервер или загружать данные с сервера, используя, соответственно, опции push или pull :
Если над проектом намереваются работать и другие программисты, сначала им надо клонировать репозиторий с сервера на своих локальных компьютерах:
В данной команде /home/swapnil/project.git — это путь к папке проекта на удалённом сервере, в вашем случае тут будет другой путь.
Затем, после клонирования, надо перейти в директорию проекта:
У вас, вместо project будет имя другой директории. Теперь можно приступать к работе над проектом, принимать изменения и отправлять их на сервер:
Мы полагаем, что вышеприведённых сведений достаточно для того, чтобы помочь тем, у кого не было опыта работы с 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:
В процессе установки Postfix система задаст вам несколько вопросов. Не стоит пропускать ответы на них, но если ответы на них не даны, можно перенастроить систему, выполнив следующую команду:
После запуска этой команды нужно указать параметр Internet Site и задать почтовый идентификатор для домена, который будет использоваться GitLab. Далее, надо будет указать имя пользователя для Postfix и почтовый адрес. Значения остальных параметров можно не менять. После установки и настройки Postfix можно заняться GitLab.
Загрузим свежий пакет отсюда с помощью wget :
Теперь установим его:
Настроим и запустим GitLab:
Теперь надо будет настроить доменное имя в конфигурационном файле, что даст возможность работать с GitLab. Откроем файл:
Сайт GitLab, открытый в браузере
Смена пароля на сайте GitLab
После того, как пароль изменён, можно войти на сайт и заняться работой с проектами.
Работа с проектами в GitLab
GitLab — это серьёзная система, имеющая массу возможностей. Как в них разобраться? Позволим себе привести тут несколько изменённую цитату из фильма «Матрица»: «Увы, невозможно рассказать о том, что умеет GitLab. Вы должны увидеть это сами».
Уважаемые читатели! Пользуетесь ли вы собственными Git-серверами? Если да — просим рассказать о том, как вы их настраиваете и поддерживаете.
Создаём Git сервер своими руками
Доброго времени суток, друзья! 🙂
В сегодняшней статье я решил немного отвлечься от процесса создания сайтов и различных рассуждений о разновидностях движков и прочих теоретических вопросов, связанных с сайтостроением.
Вместо этого я вам расскажу о своём опыте создания 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, поэтому заходим в консоль и прописываем следующее:
Данные команды позволят вам автоматически скачать из пакетного репозитория и установить на компьютер, работающий под Linux, самую последнюю версию Git.
Кстати, все действия будут выполняться в консоли, поэтому не спешите её закрывать после успешного прохождения каждого шага.
Если у вас на сервере будет установлена другая ОС, то для них вы можете скачать дистрибутивы с официального сайта Git — https://git-scm.com/downloads. На данный момент доступны решения для Mac OS X, Linux (включая его дистрибутивы – Ubuntu, Debian, Arch Linux и т.д.), а также Windows.
Шаг 2. Следующим шагом будет создание системного пользователя для работы с Git. В моём случае он так и будет назваться – git. Прописываем следующую команду:
Также нужно будет ввести пароль для пользователя. Рекомендую не придумывать что-то сверхсекретное и длинное, т.к. его потом придётся вводить каждый раз при записи и чтении из репозитория, что может раздражать вас и ваших коллег.
Шаг 3. Теперь создаём сам репозиторий. Для этого сначала переключаемся на нашего только что созданного пользователя:
Переходим в каталог, в котором будут храниться наши репозитории. Я лично решил хранить их в домашней папке пользователя, поэтому в моём случае команда выглядела так:
Шаг 4. И создаём так bare-репозиторий, т.е. чистый, не содержащий каких-либо файлов. По стандарту Git каталоги таких репозиториев должны содержать в названии окончание «.git»:
Заходим в каталог и инициализируем в нём наш bare-репозиторий:
Всё, наш репозиторий готов. Теперь перед нами будет стоять задача организации связи между сервером и клиентом, чтобы мы могли производить чтение/запись данных в репозиторий.
Шаг 5. Узнайте IP-адреса компьютеров, включённых в одну локальную сеть с вашим сервером с помощью команды, которую нужно вводить в консоли на сервере:
Если система выдаст ошибку, ссылаясь на несуществующую команду, то нужно будет предварительно установить nmap следующей командой:
По идее, если nmap вернёт вам список хостов с подробной информацией о них (их локальные IP-адреса, время ответа компьютера и т.д.), то это уже будет значить, что связь между сервером и рабочими станциями присутствует.
Если же вам этого покажется мало, то можете попробовать пропинговать какую-то конкретную станцию по её IP-адресу, который вы узнали с помощью предыдущей команды:
Думаю, и так понятно, что здесь вместо примера нужно указать реальный IP-адрес рабочей станции.
Если же вам не удалось определить IP компьютеров изложенными выше способами, то, скорее всего, что в сети существуют какие-то проблемы. Попробуйте проверить, включены ли компьютеры в сеть (наличие вставленного сетевого кабеля) и настройки подключения на вервере и рабочих станциях.
Также могут быть какие-то проблемы с сетевым оборудованием, которое связывает ваши ПК (роутер, свич, маршрутизатор и т.д.).
Итак, мы убедились в том, что физическая связь между сервером и рабочими станциями присутствует. Теперь нужно настроить передачу данных между ними.
Тут следует сказать, что связь между двумя Git-репозиториями может осуществляться несколькими способами, с помощью различных сетевых протоколов:
Я не буду сейчас заниматься обзором особенностей каждого приведённого протокола, а также плюсов и минусов его использования. Тем более, что об этом замечательно написано на официальном сайте Git — https://git-scm.com/book/ru/v2/Git-на-сервере-Протоколы.
Если хотите – почитайте на досуге 🙂
Скажу только, что для своей ситуации я выбрал SSH-протокол благодаря возможности производить как чтение данных, так и запись, причём, предварительно зашифровав их и сжав.
Также этот протокол обеспечивает безопасность операций с данными, т.к. они производятся по авторизованным каналам.
Эта возможность весьма пригодится, если в будущем понадобится организовать доступ в локальную сеть извне, т.е. работать с Git-репозиторием не только с рабочего места.
А поскольку, как я раньше говорил, такая возможность не исключается, то я решил настраивать Git сервер с заделом на будущее.
Также в пользу SSH-протокола хочу добавить, что он поддерживается большинством современных хостинг-провайдеров. Следовательно, если вы захотите развернуть Git сервер на хостинге, то SSH – то, что вам нужно, и дальнейшие настройки соединения будут актуальны также и для вашего случая.
6. Итак, при передаче данных по SSH, как и в случае других протоколов, у нас есть сервер и клиент. В нашем случае сервером будет выступать, как ни странно, машина, на которой расположен главный Git-репозиторий.
Для того, чтобы к нашему серверу можно было подключаться по SSH, нам нужно установить на нём SSH-сервер, который реализован в виде отдельной программы.
Я использовал наиболее распространённый продукт – OpenSSH, который устанавливается аналогичным Git-у способом:
По идее, в Ubuntu он должен быть установлен по умолчанию, но то ли мне дистрибутив ОС такой попался, то ли его у меня просто не было.
Собственно говоря, данная особенность и лежала в корне моих проблем, потому что я делал всё, как было указано в мануалах, которыми я пользовался при настройке Git сервера, но, когда дело доходило до копирования репозитория с сервера по SSH, Git на клиенте выдавал мне ошибки подключения по SSH.
Да и вообще странное было дело: в мануалах рекомендовали править файл authorized_keys, о котором мы ещё поговорим, а в каких конфигах прописывать использование этого файла — не указывалось.
Может быть, файл должен был подхватываться по умолчанию, но у меня этого не происходило до момента, пока я не установил OpenSSH и не настроил его.
На этом этапе сервер полностью настроен. Мы ещё будем на него заходить, но пока перенесём наши действия на сторону клиента:
Шаг 1. Прежде всего, как и на сервере, устанавливаем Git. Я уже говорил, что на клиентских машинах у меня была установлена ОС Windows. Следовательно, установка отличалась от Linux – мне нужно было скачать и установить дистрибутив.
После этого в контекстном меню проводника (появляется при клике на каталоге правой кнопкой мыши) у меня появился доступ к Git Bash и Git GUI.
Первый инструмент является аналогом консоли Linux, позволяющий общаться с Git путём специальных команд, перечень которых доступен в официальной документации.
Второй представляет собой графическую оболочку для работы с репозиторием и управления данными в нём.
Я лично пользовался Git Bash, потому что, как по мне, знание Git-команд – это уже неплохой профит, поэтому буду рассказывать о работе с ним.
Шаг 2. Теперь нам нужно сгенерировать SSH-ключ, с помощью которого будет возможна связь с сервером по протоколу SSH. Для его генерации можно воспользоваться Git Bash.
Запускаем его с помощью ярлыка, который должен был появиться после установки Git на ПК, или через контекстное меню какого-либо каталога на компьютере.
И прописываем следующую команду:
Мы вызвали утилиту для генерации SSH-ключей, которая входит в состав Git, и передали в качестве параметров генерации свой email. Если его не указывать, то SSH-ключ будет ассоциироваться с именем рабочей станции.
Также утилита предлагает указать файл, в который будет сохранён SSH-ключ, и задать пароль, который будет учитываться при генерации. Для простоты я оставил файл по умолчанию, нажав Enter, а пароль пустым, нажав на ту же клавишу ещё два раза.
В результате получился такой ключ:
Шаг 3. Теперь, когда у вас есть SSH-ключ, осталось только его скопировать и отправить вашему системному администратору, чтобы он разместил его на сервере.
Самый простой способ – это скопировать ключ прямо из консоли Git Bash путём выделения ключа и нажатии клавиш «Ctrl+Insert» для создании его копии в буфере обмена.
После осталось только вставить его в письмо и отправить администратору по почте, через Skype или другим удобным для вас способом.
Обратите внимание! Папка может быть скрытой, поэтому для того, чтобы её увидеть, вам необходимо будет включить режим отображения скрытых файлов и папок в вашей ОС.
После этого снова вернёмся на сервер Git, чтобы разместить на нём SSH-ключи, сгенерированные на клиентских машинах, для доступа по этому протоколу.
Заходим в каталог и создаём там файл:
Шаг 2. Теперь нам в него нужно будет скопировать содержимое pub-файла, который содержит SSH-ключ, либо вставить в конец authorized_keys ключ, присланный по почте в явном виде.
Рассмотрю пример с копированием содержимого файла. Допустим, файл лежит в папке /tmp:
Шаг 3. Конфигурируем OpenSSH на использование SSH-ключей доступа из файла authorized_keys. Для этого нам нужно будет отредактировать файл его настроек:
В качестве текстового редактора я использовал mcedit, у вас может быть другой.
Шаг 4. Перезапускаем (restart) или стартуем OpenSSH, если он до сих пор не был запущен от рутового пользователя:
На этом с сервером мы заканчиваем, т.к. все необходимые действия уже произведены. Теперь нам осталось записать данные на Git удалённый сервер с клиентских машин, чем мы и займёмся.
Шаг 1. Поскольку SSH-соединение между сервером и нашей рабочей станцией должно быть уже установлено, то будет не лишним ещё раз в этом убедиться.
Для этого нужно воспользоваться любым SSH-клиентом. Поскольку, напомню, у меня на компьютерах разработчиков установлена ОС Windows, то мой выбор пал на популярную утилиту PuTTY, которую можно скачать с сайта её создателя — http://www.chiark.greenend.org.uk/
Здесь, кстати, вы сможете установить как весь набор инструментов пакета PuTTY, так и скачать их по отдельности. Рекомендую всё же скачать пакет полностью и установить все компоненты. Для этого нужно загрузить инсталлятор и запустить его.
После установки на рабочем столе должен появиться ярлык PuTTY, который будет ссылаться на SSH-клиент, входящий в данный набор.
Запускаем его и в поле «Имя хоста или IP-адрес» вводим локальный IP-адрес нашего Git сервера. Порт оставляем тот, который прописан по умолчанию – 22:
Нажимаем «Open» для открытия соединения. Предварительно можно ввести имя соединения и нажать «Save», если вам нужно будет сохранить настройки для дальнейших подключений. Потом нужно будет дважды кликнуть на требуемом соединении левой кнопкой мыши.
После этого, при наличии связи с указанным сервером, откроется консоль с предложением ввести имя пользователя (git в нашем случае) и его пароль, который мы задавали ему на сервере при создании.
При успешном вводе данных вы будете авторизованы на сервере под учётной записью пользователя и сможете производить там все необходимые действия.
Кстати, в комплект PuTTY также входит генератор SSH-ключей, которым вы можете пользоваться в качестве альтернативы Git-генератору SSH. В качестве интересных особенностей данного софта есть возможность генерации SSH-файлов в PuTTY-формате, которые используются для работы в различных Git-клиентах.
Также в PuTTYgen (а именно так называется SSH-генератор PuTTY) есть возможность формирования ключей собственного формата из существующих в текстовом виде.
Я не буду сейчас рассказывать, как им пользоваться. Оставлю этот разговор на будущее, если решусь на написание статьи с обзором популярных Git-клиентов. Решиться, кстати, можете помочь мне именно вы, оставив свой отзыв в комментариях под статьёй.
Шаг 2. На момент разворачивания Git сервера лично у меня на рабочей станции уже были проекты, которые нужно было залить в серверный репозиторий.
Чтобы это сделать, я зашёл в папку со своим проектом и вызвал Git Bash через контекстное меню каталога. Аналогичного результата можно было добиться запустив Git Bash с рабочего стола и переместиться в каталог помощью команды cd.
В консоли я прописал следующее:
Данными командами я инициализировал Git-репозиторий в своём каталоге и добавил в него текущее состояние файлов и папок.
Шаг 3. Теперь нам нужно инициализировать удалённый репозиторий, который будет являться копией нашего локального проекта, с помощью команды:
Здесь, как не сложно догадаться, нужно указать имя пользователя на сервере (у нас git), имя домена (понадобится при синхронизации с Git сервером на хостинге) или его IP-адрес и путь к репозиторию на сервере.
Всё, теперь нужно создать запись в репозиторий (коммит — commit) и передать её на сервер («запушить» – от названия ответственной команды «push»):
Вот и всё. После этого на нашем Git сервере в репозиторий должны были скопироваться файлы локального проекта.
Теперь работа с Git сервером будет осуществляться по такой схеме:
В виде команд приведённый порядок действий будет выглядеть так:
Запись и чтение в этом примере происходит в ветку master нашего репозитория. Естественно, что при наличии нескольких разработчиков на одном проекте, возникнет необходимость создавать, как минимум, каждому свою ветку, если не пойти дальше и не делать отдельную для каждой задачи.
Поэтому придётся к данному перечню часто используемых команд для работы с Git добавить ещё две комманды:
Они будут производить переключение на конкретную ветку и слияние её с другой соотвтетственно. При слиянии в текущую ветку будут добавляться изменения из той, с которой она соединяется.
Как вы могли заметить, полученная нами в итоге модель Git сервера предполагает наличие в коллективе разработчиков, которые будут заниматься работой с копией проекта у себя на локальных компьютерах с последующей фиксацией изменений на сервере, и администратора, который будет заниматься добавлением новых репозиториев на сервере и SSH-ключей пользователей для работы с ними.
Когда в вашей команде появится новый человек, которому нужно будет развернуть копию проекта на его локальной машине, то ему достаточно будет установить Git, сгенерировать SSH-ключ и передать его администратору.
Для получения локальной копии репозитория ему достаточно будет выполнить всего одну команду в Git Bash:
Естественно, прописав свои значения имени пользователя, адреса сервера и пути к репозиторию на сервере.
Напоследок хотелось бы сказать пару слов о том, как менять адрес или алиас Git удаленного репозитория.
У меня, к примеру иногда возникает такая ситуация на работе, когда при неполадках с сетью сбрасывается IP-адрес Git удалённого сервера.
Тогда закоммититься невозможно, т.к. меняется адрес репозитория целиком. Что же нужно делать?
Во-первых, идем к серверу и узнаем его новый IP-адрес путем прописывания в консоли команды ipconfig, если сервер работает под Windows, или ifconfig, если под Linux.
Если Git сервер находится в одной локальной сети с вами, то, скорее всего, его айпишник будет выглядеть так:
Если у вас нет прямого доступа к серверу, то обратитесь к системному администратору, т.к. удаленно узнать IP у вас не получится, т.к. без его знания вы банально не подключитесь к машине.
По крайнем мере, я таких способов не знаю. Если вы в курсе — не жадничайте и поделитесь им в комментариях со всеми 🙂
Во-вторых, на локальной машине запускаем Git Bash в директории, для которой инициализирован репозиторий, и вводим команду, чтобы посмотреть список Git удаленных репозиториев, с которыми связан локальный:
Команда вернет результат в таком формате:
Ну, и в-третьих, копируем адрес, начинающийся с git@…, вводим следующую команду для непосредственной смены адреса и вставляем скопированный адрес, изменив IP на новый:
Всё, удалённый git репозиторий изменён. Для проверки можно ещё раз вызвать команду
Если все сделали верно, то команда вернёт уже новый адрес репозитория. Кстати, данный метод вам поможет не только при смене IP Git сервера, но и каталога репозитория на сервере.
Удалить удалённый Git репозиторий, к слову, ещё проще, т.к. не нужно вводить адрес целиком, а достаточно одного алиаса:
Итак, на этом сегодняшний гайд по созданию и настройке Git сервера и Git клиентов, в котором мы также косвенно поговорили о часто используемых операциях и командах для работы с Git репозиторием, подошёл к концу.
Надеюсь, что в итоге у вас всё получилось, как и у меня. С нетерпением жду ваших комментариев.
Также не забывайте подписаться на обновления проекта, т.к. в будущем мы обязательно продолжим сегодняшний разговор и поговорим о различных графических Git-клиентах, делающих процесс работы с репозиториями ещё проще и быстрее, а также о веб-интерфейсах репозиториев на сервере, позволяющих отображать их содержимое и манипулировать существующими проектами.
На этом прощаюсь с вами и до новых встреч! 🙂
P.S.: если вам нужен сайт либо необходимо внести правки на существующий, но для этого нет времени и желания, могу предложить свои услуги.
Более 5 лет опыта профессиональной разработки сайтов. Работа с PHP, OpenCart, WordPress, Laravel, Yii, MySQL, PostgreSQL, JavaScript, React, Angular и другими технологиями web-разработки.
Опыт разработки проектов различного уровня: лендинги, корпоративные сайты, Интернет-магазины, CRM, порталы. В том числе поддержка и разработка HighLoad проектов. Присылайте ваши заявки на email cccpblogcom@gmail.com.
И с друзьями не забудьте поделиться 😉