Как сделать свой git сервер

Собственный Git на Windows

Быстро пробежимся по основным пунктам. У меня стоит Windows Server 2012 R2. И показывать я буду на ней. Для Windows Server 2008 все примерно также. Предполагается, что Виндасервер у вас сконфигурирован и настроен. Если это не так – идите к документации)

IIS Сервер + .NET Framework.

Запускаем Server Manager (диспетчер серверов) -> Manage (Управление) -> Add Roles and Features (Добавить роли и компоненты) …

да да у меня виндосервер на русском.

Выбрать Role-based or Feature-based Installation (установка ролей или компонентов)

Далее выбираем наш сервер

В ролях выбираем Web Server (IIS).

В компонентах жмякаем на .NET framework 4.5 и на последнем шаге выбираем нужные настройки.

Установка… Потребует перезагрузки сервера. Загружаем .NET Framework 4.6 и ставим его. Все теперь можно ребутиться.

Для любителей консоли…

Git Server

Всё, теперь можно перейти к непосредственно развёртыванию git сервера. Разархивируем содержимое дистрибутива в wwwroot IIS-сервера ( C:\inetpub\wwwroot ) и даём права учетной записи IIS_IUSERS на модификацию каталога App_Data .

Запускаем IIS Manager и конвертируем Git в приложение.

После конвертации жмем Action – Browse (Управление приложением – обзор) и у нас должен открыться сайтик с формой для входа. Теперь он доступен по адресу IP сервера\git в локальной сети. При желании его можно вывезти во внешнюю сеть и вообще делать с ним все что душе угодно!

Настройка.

По стандарту логин пароль для входа admin\admin.

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

Можно добавлять новых пользователей и осуществлять контроль видимости репозиториев, выдавать исключительные права пользователям. Также можно объединять пользователей в команды и управлять ими. На пример команде Core Developers будут доступны все ветки в репозитории, а команде Testers только ветка Master.

Я надеюсь данная статья была полезна для вас. Ставьте Like за встроенный редактор кода и подсветку синтаксиса))) Приятного кодинга!

Как настроить собственный сервер 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, хотя она может быть ещё больше, если у вас есть большие двоичные файлы и много изменений с течением времени.

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

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

URL-адрес начинается с git@, потому что он подключается через SSH как пользователь git.

example.com — это адрес вашего сервера, который можно указать как имя хоста или IP

:repository.git в конце на самом деле является именем пути, а не просто идентификатором. Путь указывается относительно домашнего каталога пользователя git, поэтому, если вы разместили репозиторий в другом месте, то вам нужно указать абсолютный путь.

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

Name already in use

MyDocs / GIT / Create-self-hosted-private-git-server.md

Go to file T
Go to line L
Copy path
Copy permalink

Open with Desktop
View raw
Copy raw contents Copy raw contents

Copy raw contents

Как создать свой собственный git-сервер на Linux

Необходимо сделать себе доступ на сервер через SSH по паблик ключу.

добавить пользователя git

Создать каталог пользователя и Скопировать публичный ключ для пользователя git

Залогинится под git и создать Репозитории

На локальной машине разработчика отвязываем репозиторий от платных удаленных нестабильных BitBucket?

предварительно выведем текущий удаленный репозиторий

Привязываем наш новенький приватный репо и пушим в него

Ура. Все получилось. И пушится и пулится и входит и выходит. Я настроил себе приватный репо. Гудбай BitBucket

Footer

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

4.2 Git на сервере — Установка Git на сервер

Рассмотрим теперь установку сервиса Git с поддержкой этих протоколов на сервер.

Здесь мы приводим команды и шаги, необходимые для базовой, упрощённой установки на Linux-сервер, но эти сервисы можно запустить и на MacOS или Windows сервере. На самом деле, установка боевого сервера в вашей инфраструктуре неминуемо будет иметь отличия в настройках безопасности или инструментах операционной системы, но мы надеемся дать вам общее понимание происходящего.

Для того чтобы приступить к установке любого сервера Git, вы должны экспортировать существующий репозиторий в новый голый репозиторий — репозиторий без рабочего каталога. Делается это просто. Чтобы создать новый голый репозиторий — во время клонирования используйте параметр —bare . По существующему соглашению, каталоги с голыми репозиториями заканчиваются на .git , например:

Теперь у вас должна быть копия данных из каталога Git в каталоге my_project.git .

Грубо говоря, это эквивалентно команде:

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

Размещение голого репозитория на сервере

Теперь, когда у вас есть голая копия вашего репозитория, осталось поместить её на сервер и настроить протоколы. Предположим, что вы уже настроили сервер git.example.com , имеете к нему доступ по SSH и хотите разместить все ваши репозитории Git в каталоге /srv/git . Считая, что /srv/git уже есть на сервере, вы можете добавить ваш новый репозиторий копированием голого репозитория:

Теперь другие пользователи, имеющие доступ к серверу по SSH и права на чтение каталога /srv/git , могут клонировать ваш репозиторий выполнив команду:

Если у пользователя есть права записи в каталог /srv/git/my_project.git , он автоматически получает возможность отправки изменений в репозиторий.

Git автоматически добавит права на запись в репозиторий для группы при запуске команды git init с параметром —shared . Следует отметить, что при запуске этой команды коммиты, ссылки и прочее удалены не будут.

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

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

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

Малые установки

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

SSH доступ

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

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

Есть несколько способов предоставить доступ всем участникам вашей команды. Первый — создать учётные записи для каждого, это просто, но может быть весьма обременительно. Вероятно, вы не захотите для каждого пользователя выполнять adduser (или useradd ) и задавать временные пароли.

Второй способ — это создать на сервере пользователя git , попросить всех участников, кому требуется доступ на запись, прислать вам открытый ключ SSH и добавить эти ключи в файл

/.ssh/authorized_keys в домашнем каталоге пользователя git . Теперь все будут иметь доступ к этой машине используя пользователя git . Это никак не повлияет на данные в коммите — пользователь, под которым вы соединяетесь с сервером по SSH, не воздействует на созданные вами коммиты.

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