Собственный сервер Git на базе Ubuntu или Debian/GNU Linux
Я встречал в сети много tutorial’ов по установке своего сервера git как на gitweb, так и на webdav, но, увы, они либо были только по одному из вышеназванных пунктов, не освещая другой, либо банально не работали. Вчера возникла необходимость поднять свой сервер репозиториев. Потратил пару часов — поднял, теперь хочу поделиться опытом, потому что считаю проблему актуальной 🙂
По данному руководству был создан репозиторий git.shadowircd.net
Для начала сделаем install некоторых пакетов aptitude:
aptitude install git-core git-svn gitweb
a2enmod dav
a2enmod dav_fs
a2enmod rewrite
a2enmod env
$my_uri = “http://git.domain.tld”; # адрес репозиториев
$site_name = “git.domain.tld”; # название сайта, отображается в заголовке
$projectroot = “/www/git.domain.tld/htdocs/git/”; # путь к репозиториям git на жёстком диске
$git_temp = “/tmp”;
$home_link = $my_uri; # ссылка на «домашнюю страничку»
# $home_text = “indextext.html”; # текст, можно расскоментировать и вставить свой
$projects_list = $projectroot;
$stylesheet = “/gitweb/gitweb.css”;
$logo = “/gitweb/git-logo.png”;
$favicon = “/gitweb/git-favicon.png”;
$projects_list_description_width = 40;
DocumentRoot /www/git.domain.tld/htdocs
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
RewriteEngine on
RewriteRule ^/([a-zA-Z0-9_\-]+\/\.git)/?(\?.*)?$ /cgi-bin/gitweb.cgi/$1 [L,PT]
SetEnv GITWEB_CONFIG /www/git.domain.tld/gitweb.conf
Alias /gitweb /usr/share/gitweb/
Options FollowSymLinks
AllowOverride None
Order allow,deny
allow from all
Источник
How to Run Your Own Git Server
Learn how to set up your own Git server in this tutorial from our archives.
Git is a versioning system developed by Linus Torvalds, that is used by millions of users around the globe. Companies like GitHub offer code hosting services based on Git. According to reports, GitHub, a code hosting site, is the world’s largest code hosting service. The company claims that there are 9.2M people collaborating right now across 21.8M repositories on GitHub. Big companies are now moving to GitHub. Even Google, the search engine giant, is shutting it’s own Google Code and moving to GitHub.
Run your own Git server
GitHub is a great service, however there are some limitations and restrictions, especially if you are an individual or a small player. One of the limitations of GitHub is that the free service doesn’t allow private hosting of the code. You have to pay a monthly fee of $7 to host 5 private repositories, and the expenses go up with more repos.
In cases like these or when you want more control, the best path is to run Git on your own server. Not only do you save costs, you also have more control over your server. In most cases a majority of advanced Linux users already have their own servers and pushing Git on those servers is like ‘free as in beer’.
In this tutorial we are going to talk about two methods of managing your code on your own server. One is running a bare, basic Git server and and the second one is via a GUI tool called GitLab. For this tutorial I used a fully patched Ubuntu 14.04 LTS server running on a VPS.
Install Git on your server
In this tutorial we are considering a use-case where we have a remote server and a local server and we will work between these machines. For the sake of simplicity we will call them remote-server and local-server.
First, install Git on both machines. You can install Git from the packages already available via the repos or your distros, or you can do it manually. In this article we will use the simpler method:
Then add a user for Git.
In order to ease access to the server let’s set-up a password-less ssh login. First create ssh keys on your local machine:
It will ask you to provide the location for storing the key, just hit Enter to use the default location. The second question will be to provide it with a pass phrase which will be needed to access the remote server. It generates two keys – a public key and a private key. Note down the location of the public key which you will need in the next step.
Now you have to copy these keys to the server so that the two machines can talk to each other. Run the following command on your local machine:
Now ssh into the server and create a project directory for Git. You can use the desired path for the repo.
Then change to this directory:
Then create an empty repo:
We now need to create a Git repo on the local machine.
And change to this directory:
Now create the files that you need for the project in this directory. Stay in this directory and initiate git:
Now add files to the repo:
Now every time you add a file or make changes you have to run the add command above. You also need to write a commit message with every change in a file. The commit message basically tells what changes were made.
In this case I had a file called GoT (Game of Thrones review) and I made some changes, so when I ran the command it specified that changes were made to the file. In the above command ‘-a’ option means commits for all files in the repo. If you made changes to only one you can specify the name of that file instead of using ‘-a’.
Until now we have been working on the local server. Now we have to push these changes to the server so the work is accessible over the Internet and you can collaborate with other team members.
Now you can push or pull changes between the server and local machine using the ‘push’ or ‘pull’ option:
If there are other team members who want to work with the project they need to clone the repo on the server to their local machine:
Here /home/swapnil/project.git is the project path on the remote server, exchange the values for your own server.
Then change directory on the local machine (exchange project with the name of project on your server):
Now they can edit files, write commit change messages and then push them to the server:
I assume this is enough for a new user to get started with Git on their own servers. If you are looking for some GUI tools to manage changes on local machines, you can use GUI tools such as QGit or GitK for Linux.
Using GitLab
This was a pure command line solution for project owner and collaborator. It’s certainly not as easy as using GitHub. Unfortunately, while GitHub is the world’s largest code hosting service; its own software is not available for others to use. It’s not open source so you can’t grab the source code and compile your own GitHub. Unlike WordPress or Drupal you can’t download GitHub and run it on your own servers.
As usual in the open source world there is no end to the options. GitLab is a nifty project which does exactly that. It’s an open source project which allows users to run a project management system similar to GitHub on their own servers.
You can use GitLab to run a service similar to GitHub for your team members or your company. You can use GitLab to work on private projects before releasing them for public contributions.
GitLab employs the traditional Open Source business model. They have two products: free of cost open source software, which users can install on their own servers, and a hosted service similar to GitHub.
The downloadable version has two editions – the free of cost community edition and the paid enterprise edition. The enterprise edition is based on the community edition but comes with additional features targeted at enterprise customers. It’s more or less similar to what WordPress.org or WordPress.com offer.
The community edition is highly scalable and can support 25,000 users on a single server or cluster. Some of the features of GitLab include: Git repository management, code reviews, issue tracking, activity feeds, and wikis. It comes with GitLab CI for continuous integration and delivery.
Many VPS providers such as Digital Ocean offer GitLab droplets for users. If you want to run it on your own server, you can install it manually. GitLab offers an Omnibus package for different operating systems. Before we install GitLab, you may want to configure an SMTP email server so that GitLab can push emails as and when needed. They recommend Postfix. So, install Postfix on your server:
During installation of Postfix it will ask you some questions; don’t skip them. If you did miss it you can always re-configure it using this command:
When you run this command choose “Internet Site” and provide the email ID for the domain which will be used by Gitlab.
In my case I provided it with:
Use Tab and create a username for postfix. The Next page will ask you to provide a destination for mail.
In the rest of the steps, use the default options. Once Postfix is installed and configured, let’s move on to install GitLab.
Download the packages using wget (replace the download link with the latest packages from here) :
Then install the package:
Now it’s time to configure and start GitLabs.
You now need to configure the domain name in the configuration file so you can access GitLab. Open the file.
In this file edit the ‘external_url’ and give the server domain. Save the file and then open the newly created GitLab site from a web browser.
By default it creates ‘root’ as the system admin and uses ‘5iveL!fe’ as the password. Log into the GitLab site and then change the password.
Once the password is changed, log into the site and start managing your project.
GitLab is overflowing with features and options. I will borrow popular lines from the movie, The Matrix: “Unfortunately, no one can be told what all GitLab can do. You have to try it for yourself.”
Источник
Создаём 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 или другим удобным для вас способом.
Можно также отправить файл с 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.
Заходим в каталог и создаём там файл:
Шаг 2. Теперь нам в него нужно будет скопировать содержимое pub-файла, который содержит SSH-ключ, либо вставить в конец authorized_keys ключ, присланный по почте в явном виде.
Рассмотрю пример с копированием содержимого файла. Допустим, файл лежит в папке /tmp:
Шаг 3. Конфигурируем OpenSSH на использование SSH-ключей доступа из файла authorized_keys. Для этого нам нужно будет отредактировать файл его настроек:
В качестве текстового редактора я использовал mcedit, у вас может быть другой.
Ищем в нём строку AuthorizedKeysFile .ssh/authorized_keys и раскомментируем её, если в её начале присутствует символ «#».
Шаг 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 сервером будет осуществляться по такой схеме:
- изменения из главного репозитория копируются на локальный компьютер (текущие правки, не совпадающие с кодом на 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.
И с друзьями не забудьте поделиться 😉
Источник
