4.2 Git на сервере — Установка 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.

gosha20777

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

January 05, 2018 | 3 Minute Read

Н у вот наступил 11111100010 год ии у меня появилось свободная минутка, чтобы написать тут что-то полезное:-)

Случилось так, что понадобился приватный git репозиторий, а покупать VIP аккаунт на github не хотелось, да и политика безопасности компании, для которой разрабатывается проект, не позволяет это делать. По этому было принято решение о развертывании собственного git-сервера. Так как я C# developer, то речь пойдет конечно же о Windows Server и IIS Server. Пользователям Linux скажу, что там установка этого «богатства» еще проще и состоит из пары команд в терминале.

Немного о платформе.

Данный git-server был написан на C# на ASP.NET и представляет собой Web приложение. Все исходные коды доступны тут. Все желающие могут ознакомиться и оценить кривизну кода) А мы поехали дальше -)

Как его ставить?

Для успешной установки нам нужны

1. Сам сервер на Windows Server 2008 R2/2012/2012 R2/2016 (кто-то сидит на ней?)
2. Internet Information Services (IIS) 7 или 8
3. .NET Framework 4.6
4. visual redist 2012/2015 и CLR
5. Server дистрибутив

Быстро пробежимся по основным пунктам. У меня стоит 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 за встроенный редактор кода и подсветку синтаксиса))) Приятного кодинга!

Pro Git

Страницы

воскресенье, 1 марта 2015 г.

Установка и настройка сервера Git на Windows Server (20xx)

Тут я, вкратце, опишу один из возможных вариантов установки сервера Git под Windows Server. Хотя эти рекомендации так же можно применить и для установки сервера Git на обычную рабочую станцию под Windows от XP и выше.

И так скачиваем дистриб от сель. Кстати там же можете почитать и процедуру установки, там все более просто без заморочек на безопасность и обновления Git под винду до текущей версии.

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

И так скачали. Понеслась установка.

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

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

И так тушим Apache.

И запускаем GitStack сразу по окончании установки. Просто оставляем галку включённой.

Запустится ваш браузер по умолчанию и выведет вас сразу на страничку сервера

Логинимся с учеткой по умочанию

Сразу же меняем пароль администратора

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

И перезапускаем сервис. Идем опять в админку сервера и меняем порты на которых он будет висеть.

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

После смены портов естественно в адресной строке надо будет указывать уже порт, чтобы дальше рулить админкой. Рестартуем GitStack

Ну и я стартовал свой Apache. У вас этого может и не быть. То есть по ходу у меня запущено два веб сервера.

Заходим по новому порту и донастраиваем чтобы слушал еще и по HTTPS.

Проверяем работу HTTPS

Все теперь можно высовывать морду сервера наружу в большой мир. Но осторожно ….

И чтобы большой мир увидел эту морду надо открыть порт на локальном файрволе сервера, так как по умолчанию GitStack открывает порт 80

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

Далее создаем пользователя

И даем пользователю права на репозиторий

И еще немного настроек безопасности. Если зайти на сервер без указания папки GitStack то увидим такое

Это не есть гуд. Правим указанный файлик настроек

Рестартуем вебсервис GitStack и видим уже такую картину.

Теперь клонируем репозиторий с нашего сервера на локальную машину

Настраиваем локально Git и делаем первый локальный коммит

И далее заливаем его на сервер. Но делаем это по особенному, так как у нас на сервере само подписанный сертификат.

У сервера достаточно приятная и понятная морда для отслеживания коммитов через веб интерфейс

Ну и на последок надо заметить что на момент написания статьи в комплекте с GitStack шла не самая последняя версия Git

Я установил последнюю версию Git, переписал пути в переменной PATH и все заработало на новой версии

Ну и на последок можно сказать что можно вписать в конфиг проекта строку

$ git config —local http.sslVerify false

Чтобы каждый раз не писать в командах отмену проверки валидности сертификата.