Git сервер свой: Создание, настройка и использование собственного Git-сервера

Создание, настройка и использование собственного Git-сервера

Материал, перевод которого мы сегодня публикуем, посвящён настройке Git-серверов. Git — это система управления версиями, разработанная Линусом Торвальдсом. Git пользуются миллионы людей во всём мире. Компании, вроде GitHub, предлагают службы хостинга кода, основанные на Git. По информации, которую можно найти в различных публикациях, GitHub является крупнейшим сервисом для хостинга IT-проектов. В частности, в 2017-м году сообщество GitHub достигло 24 миллионов разработчиков, которые трудятся над 67 миллионами репозиториев. В наши дни GitHub пользуются абсолютно все — от программистов-одиночек, до крупных организаций. Надо сказать, что даже компания Google перешла на GitHub, закрыв собственный проект схожей направленности.

Зачем нужен собственный Git-сервер?

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

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

В этом руководстве мы поговорим о двух подходах к управлению кодовой базой с использованием собственного Git-сервера. Первый заключается в использовании обычного Git-сервера, а второй — в применении инструмента с графическим интерфейсом GitLab. В качестве платформы для экспериментов тут используется сервер на полностью пропатченной Ubuntu 14.04 LTS, развёрнутый на VPS.

Использование Git

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

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

sudo apt-get install git-core

Затем добавим пользователя для Git:

sudo useradd git
passwd git

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

Создадим ssh-ключи на локальном компьютере:

ssh-keygen -t rsa

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

Вышеописанная команда генерирует два ключа — открытый и закрытый. Запишите или запомните расположение открытого ключа. Он понадобится нам на следующем шаге.

Теперь надо скопировать эти ключи на сервер, что даст возможность наладить канал связи между двумя машинами. На локальном компьютере выполните следующую команду:

cat ~/.ssh/id_rsa.pub | ssh git@remote-server "mkdir -p ~/.ssh && cat >>  ~/.ssh/authorized_keys"

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

git@server:~ $ mkdir -p /home/swapnil/project-1.git

Затем перейдите в эту директорию:

cd /home/swapnil/project-1.git

Создайте пустой репозиторий:

git init --bare

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

Initialized empty Git repository in /home/swapnil/project-1.git

Теперь нужно создать Git-репозиторий на локальной машине. Для этого создаём директорию:

mkdir -p /home/swapnil/git/project

Переходим в неё:

cd /home/swapnil/git/project

Далее, создаём в ней файлы проекта, и, оставаясь в ней, инициализируем репозиторий:

git init

Об успешной инициализации репозитория можно судить по такому сообщению:

Initialized empty Git repository in /home/swapnil/git/project

Теперь добавим файлы проекта в репозиторий:

git add .

С этого момента, после добавления в проект новых файлов или после изменения существующих, нужно будет выполнять вышеописанную команду (git add .). Кроме того, нужно будет выполнять команду git commit, задавая сообщения, описывающие коммиты. Выглядит это примерно так:

git commit -m "message" -a
[master (root-commit) 57331ee] message
 2 files changed, 2 insertions(+)
 create mode 100644 GoT.txt
 create mode 100644 writing.txt

В нашем случае здесь имеется файл, который называется GoT (в нём лежит текст обзора Game of Thrones), в который внесены некоторые изменения. Изменения внесены и в другой файл. Поэтому при выполнении команды система сообщила о том, какие изменения были внесены в файлы. В вышеописанной команде опция -a означает обработку всех файлов репозитория. Если вы внесли изменения лишь в один файл, можно, вместо опции -a, указать имя этого файла.

Например:

git commit -m "message" GoT.txt
[master e517b10] message
 1 file changed, 1 insertion(+)

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

git remote add origin ssh://git@remote-server/repo-<wbr< a="">>path-on-server..git

Теперь можно отправлять изменения с локальной машины на сервер или загружать данные с сервера, используя, соответственно, опции push или pull:

git push origin master

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

git clone git@remote-server:/home/swapnil/project.git

В данной команде /home/swapnil/project.git — это путь к папке проекта на удалённом сервере, в вашем случае тут будет другой путь.

Затем, после клонирования, надо перейти в директорию проекта:

cd /project

У вас, вместо project будет имя другой директории. Теперь можно приступать к работе над проектом, принимать изменения и отправлять их на сервер:

git commit -m 'corrections in GoT.txt story' -a
git push origin master

Мы полагаем, что вышеприведённых сведений достаточно для того, чтобы помочь тем, у кого не было опыта работы с 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:

sudo apt-get install postfix

В процессе установки Postfix система задаст вам несколько вопросов. Не стоит пропускать ответы на них, но если ответы на них не даны, можно перенастроить систему, выполнив следующую команду:

sudo dpkg-reconfigure postfix

После запуска этой команды нужно указать параметр Internet Site и задать почтовый идентификатор для домена, который будет использоваться GitLab. Далее, надо будет указать имя пользователя для Postfix и почтовый адрес. Значения остальных параметров можно не менять. После установки и настройки Postfix можно заняться GitLab.

Загрузим свежий пакет отсюда с помощью wget:

wget https://downloads-packages.s3.amazonaws.com/ubuntu-14.04/gitlab_7.9.4-omnibus.1-1_amd64.deb

Теперь установим его:

sudo dpkg -i gitlab_7.9.4-omnibus.1-1_amd64.deb

Настроим и запустим GitLab:

sudo gitlab-ctl reconfigure

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

nano /etc/gitlab/gitlab.rb

В этом файле надо будет отредактировать параметр external_url, указав здесь доменное имя сервера. После редактирования файла его надо сохранить, после чего только что созданный GitLab-сайт можно открыть в браузере.
Сайт GitLab, открытый в браузере

По умолчанию система создаёт учётную запись администратора с именем root и паролем 5iveL!fe. Сразу после первого входа на сайт следует поменять пароль.

Смена пароля на сайте GitLab

После того, как пароль изменён, можно войти на сайт и заняться работой с проектами.

Работа с проектами в GitLab

GitLab — это серьёзная система, имеющая массу возможностей. Как в них разобраться? Позволим себе привести тут несколько изменённую цитату из фильма «Матрица»: «Увы, невозможно рассказать о том, что умеет GitLab. Вы должны увидеть это сами».

Уважаемые читатели! Пользуетесь ли вы собственными Git-серверами? Если да — просим рассказать о том, как вы их настраиваете и поддерживаете.

Поднимаем собственный git сервер GitBlit на хостинге Openshift / Хабр

Привет, Хабр!

Все программисты делятся на тех, кто использует систему контроля версий, и тех кто ещё ёё не использует. Одной из самых популярных на сегодняшний день, является git. И хотя его структура направлена на децентрализованное хранение данных, все мы пользуемся github, assembla, bitbucket или githost. Главный недостаток этих хостингов, в том, что это чужие проекты, которые в любой момент могут прикрыть ваш аккаунт или слить данные налево. И тут на сцене появляется GitBlit! Git сервер на Java, полностью контролируемый вами, с множеством плюшек и веб-интерфейсом. Сегодня будем запускать его на бесплатном хостинге от Redhat.

Узнав в начале лета про бесплатный хостинг от Redhat, сразу захотел что-нибудь там разместить, однако была проблемка: веб-разработкой не занимаюсь, проектов нет и вроде как ни какой хостинг мне не нужен. Наиболее падок человек на халяву, а это была именно халява, поэтому мой мозг выдал идею: «А давай сделаем свой собственный git сервер!». После гугления я обнаружил только один git сервер на Java, который не только активно разрабатывался, но и мог, по заверениям автора, работать на хостинге openshift. После тестов и введения в активное пользование появилось жгучие желание рассказать о нем всем в округе. Сразу было написано полстатьи, но вдруг наступило лето, и, как следствие, все проекты были заморожены до осени. Осень наступила, я наконец дописал статьи и представляю её на ваш суд.
Описание возможностей честно содрано с сайта и переведено на наш великий и могучий.

Четыре типа конфигураций контроля доступа для каждого хранилища:

• Анонимный просмотр, клонирование и загрузка в репозиторий
• Авторизованная загрузка в репозиторий
• Авторизованные клонирование и загрузка в репозиторий
• Авторизованные просмотр, клонирование и загрузка в репозиторий
• Заморозка репозитория (только для чтения)

Основные плюшки:

• Основано на JGit SmartHTTP сервлете
• Возможность объединения с другими серверами Gitblit
• RSS / JSON RPC интерфейс
• Кроссплатформенный Java Gitblit-менеджер
• Веб-интерфейс адаптированный для телефонов, планшетов и обычных компьютеров
• Использование groovy скриптов в хуках перед загрузкой на сервер и после; можно задать действие хуков для отдельного репозитория или глобально, для всех
• Уведомления по электронной почте после загрузки на сервер (через скрипт sendmail.groovy)
• Индексация Lucene ветвей репозитория
• Администраторы могут создавать, редактировать, переименовывать или удалять репозитории, пользователей и группы через веб-интерфейс или интерфейс RPC(менеджер)
• Владельцам репозитория доступно редактирование через веб-интерфейс
• Администраторы и владельцы репозитория могут установить главную ветвь через веб-интерфейс или интерфейс RPC
• LDAP аутентификации и дополнительный LDAP список пользователей
• Интеграция с gravatar
• Поддерживается отображения Git тегов
• Поддерживается отображения GH-страниц (Jekyll не поддерживается)
• Поддерживается отображения файлов Markdown
• Статистика ветвей (используется Google Charts)
• RSS каналы ветвей
• Поддерживается использование часового пояса браузера при отображении даты и времени
• Поддерживается скрытие e-mail адресов автора и коммиттера
• Регистронезависимый поиск по сообщениям коммитов, авторам и коммиттерам
• Подсветка синтаксиса исходного кода
• Дополнительные утилиты
• Страница документации, содержащая все Markdown файлы репозитория
• Страница Ticgit (на основе последнего выпуска MIT bf57b032 2009-01-27)

Языки:

• Английский
• Японский
• Испанский
• Польский

Есть желание перевести на Великий и Могучий?
Добро пожаловать на www.getlocalization.com/gitblit

Скриншоты: gitblit.com/screenshots.html

Демо сервер: demo-gitblit.rhcloud.com

Установка

Регистрируемся на openshift
Создаём JBoss Application Server https://openshift.redhat.com/app/console/application_types/jbossas-7
Дальше, следуя инструкциям, добавляем свой ssh-ключ и выполняем git clone.
У меня, например так:

git clone ssh://[email protected]/~/git/habr.git/

Переходим в папку приложения:

cd habr/

Очищаем папку от стандартной заглушки:

rm -R *

Скачиваем gitblit:

wget https://gitblit.googlecode.com/files/express-1.1.0.zip

Разархивируем в папку habr и удаляем архив:

unzip express-1.1.0.zip && rm express-1.1.0.zip

Настраиваем конфиг по адресу: habr/deployments/ROOT.war/WEB-INF/web.xml

Устанавливаем значения true:
web.enableRpcManagement

web.enableRpcAdministration

А у web.forwardSlashCharacter на !

Как здравомыслящие параноики перенаправляем весь трафик через https.

Создаём файл jboss-web.xml в этой же папке (WEB-INF) со следующим содержанием:

<jboss-web>  
      <security-domain>jboss-web-policy</security-domain>  
      <valve>  
        <class-name>org.jboss.web.rewrite.RewriteValve</class-name>  
      </valve>  
</jboss-web>

Создаём файл rewrite.properties в этой же папке (WEB-INF) со следующими правилами переадресации:

RewriteCond %{HTTP:X-Forwarded-Proto} http  
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

На этом настройка серверной части закончена.

Заливаем данные на сервер, выполняя сакральное:

git add .
git commit -m 'Init git server'
git push

Теперь последний этап настройки.

Скачиваем менеджер для удалённого администрирования gitblit: gitblit.googlecode.com/files/manager-1.1.0.zip

Подключаемся к нашему серверу habr-dark008.rhcloud.com, логин и пароль стандартные: admin, admin.

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

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

Более тонкая настройка: gitblit.com/setup.html

Исходники: github.com/gitblit или code.google.com/p/gitblit/source/list
Баг-трекер: code.google.com/p/gitblit/issues/list
Обсуждение: groups.google.com/group/gitblit
Google+: plus.google.com/114464678392593421684

Спасибо Суворову Андрею за рецензирование текста.

Собственный 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 и ставим его. Все теперь можно ребутиться.

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

Start /w pkgmgr /iu:IIS-WebServerRole;
IIS-WebServer;
IIS-CommonHttpFeatures;
IIS-StaticContent;
IIS-DefaultDocument;
IIS-DirectoryBrowsing;
IIS-HttpErrors;
IIS-HealthAndDiagnostics;
IIS-HttpLogging;
IIS-LoggingLibraries;
IIS-RequestMonitor;
IIS-Security;
IIS-RequestFiltering;
IIS-HttpCompressionStatic;
IIS-WebServerManagementTools;
IIS-ManagementConsole;
WAS-WindowsActivationService;
WAS-ProcessModel;
WAS-NetFxEnvironment;
WAS-ConfigurationAPI

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.

P.s.

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

« Л.Е.Т.О. 2017

Расставим точки над .NET Core и .NET Standard »

Свой GitLab сервер — KAZARIN OnLine

Доброго времени суток, коллеги.

На протяжении уже полутора лет работаю в области, которую сейчас принято называть DevOps, поэтому решил начать делиться некоторыми знаниями и наработками. Наработки будут на базе моих личных фриланс проектов, тк про основное место деятельности лучше не упоминать — бумажки там всякие подписаны и пр)

Итак, о чем будет эта статья — она будет о том, как организовать свой собственный современный Git сервер внутри команды/компании. Почем так важно иметь свой сервер, почему бы например не воспользоваться GitLab облаком, Github, Bitbucket и иже с ними?

Во первых — у проекта могут быть свои требования безопасности и приватности, скажем -не пользоваться сторонними сервисами

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

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

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

Я думаю этих причин уже достаточно! Да, я согласен — есть моменты где стоит пойти и купить услугу или хватит бесплатного тарифа, но есть и ситуации описанные выше.

Итак, эта статья описывает простую установку и настройку Gitlab в связке с корпоративной Active Directory для авторизации и так же является предисловием для другой статьи ( по эксплуатации).

У многих системных администраторов наверняка зреет вопрос — «если я НЕ работаю в этой области, нужна ли мне эта хрень»? Я отвечу — да, нужна. Как минимум Вам стоит познакомиться с Git и существующими облачными решениями. Если вы в своей работе пишите какие-то скрипты, утилиты ( а вы должны, вы же администратор а не эникей — ваша работа в том числе автоматизировать свою деятельность а не просто кнопки жать), формируете конфиги для сервисов — то есть так или иначе работаете с чем-то в текстовом виде что стоит версионировать, Вам стоит начать использовать Git для себя а лучше в своей компании! Тут то вам и может пригодиться собственный Git сервер. И на мой взгляд, free opensource  версия Gitlab тут подойдет как нельзя кстати!

Если Вы разработчик или DevOps инженер — вы и так прекрасно знаете что это и зачем…

Gitlab это сервис, реализующий для нас систему контроля версий на базе популярного (стандарт де факто) движка и протокола git.

Подробнее что это такое и зачем- читайте в Википедии:

Мы используем версию Gitlab CE — Community Edition, она же бесплатная и свободно распространяемая. Ее можно поставить на свой хостинг и пользоваться. Что мы и используем. Подробнее о Gitlab CE: https://about.gitlab.com/pricing/self-managed/feature-comparison/

Проект, в котором мне пришлось «поднимать» свой Gitlab сервер, с моей же подачи использует Proxmox VE в качестве системы виртуализации поверх нескольких железных серверов. Вся серверная инфраструктура компании так или иначе представлена набором виртуальных машин. Под Gitlab была использована обычная виртуальная машина на базе Ubuntu x64.

Что касается Proxmox — Я использую опять же comunity edition версию, однако устанавливаю ее не из «коробочного дистибутива», а поверх debian (увы, поверх других дистрибутивов установка не поддерживается).

Что из себя представляет vm под GitLab:

root@git:~# uname -r
4.4.0-138-generic

root@git:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.5 LTS
Release: 16.04
Codename: xenial

root@git:~# free -h
total used free shared buff/cache available
Память: 7,8G 1,6G 4,8G 86M 1,4G 5,8G
Подкачка: 974M 364K 974M

root@git:~# cat /proc/cpuinfo | grep name
model name : Common KVM processor
model name : Common KVM processor

Да, Ubuntu не самая свежая как и ядро, однако статья написана на много позже развертывания системы… На тот момент 18.04 еще не вышла.

Рекомендуемые системные требования: https://docs.gitlab.com/ee/install/requirements.html#cpu

Опустим детали установки и настройки VM и гостевой ОС — тут все взрослые, думаю справитесь…

Установка самого gitlab:

apt-get update
apt-get install ca-certificates curl openssh-server
cd /tmp
curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
bash /tmp/script.deb.sh
apt-get install gitlab-ce

vim /etc/gitlab/gitlab.rb # правим параметр external_url

gitlab-ctl reconfigure

Небольшой тюнинг ОС — Настройка ssh сервера чтобы без ключа не ходили! («…а то ходют тут всякие…» (с) )

sed -i ‘s/PermitRootLogin yes/PermitRootLogin no/g’ /etc/ssh/sshd_config
sed -i ‘s/PermitRootLogin without-password/PermitRootLogin no/g’ /etc/ssh/sshd_config
service ssh reload

Все, Gitlab установлен!

Авторизация через AD — делаем для gitlab учетку в AD и начинаем интеграцию:

vim /etc/gitlab/gitlab.rb

gitlab_rails[‘ldap_enabled’] = true
gitlab_rails[‘ldap_servers’] = YAML.load <<-‘EOS’
main:
label: ‘LDAP’
host: ‘FQDN ВАШЕГО КОНТРОЛЛЕРА ДОМЕНА’
port: 389
uid: ‘sAMAccountName’
method: ‘plain’
bind_dn: ‘CN=GITUSER,OU=ServiceUsers,OU=*OU где искать пользователей*,DC=*имя-*,DC=*-вашего-,DC=*-домена*’
password: ‘PASSWORD’
timeout: 10
active_directory: true
allow_username_or_email_login: false
block_auto_created_users: false
base: ‘OU=*OU где искать пользователей*,DC=*имя-*,DC=*-вашего-,DC=*-домена*’
user_filter: ‘(memberof=CN=gitlab_users,OU=AccessGroups,OU=*OU где искать пользователей*,DC=*имя-*,DC=*-вашего-,DC=*-домена*)’
EOS

Небольшое отступление с комментариями:

1. Для gitlab был создан пользователь GITUSER с паролем PASSWORD в структуре OU домена «OU=ServiceUsers» (‘CN=GITUSER,OU=ServiceUsers,OU=*OU где искать пользователей*,DC=*имя-*,DC=*-вашего-,DC=*-домена*’)
2. Пользователь этот был лишен всяческих доменных привилегий путем удаления из группы «пользователи домена» ( для этого создаете любую группу пустышку, добавляете пользователя в нее, делаете эту группу для него первичной и удаляете все лишние из настроек пользователя)
3. Использован фильтр ( чтобы не все доменные пользователи могли логиниться) — по членству в группе  «gitlab_users» из OU AccessGroups (таковые были созданы). В итоге те, кто входит в эту группу- могут и в Gitlab (user_filter: ‘(memberof=CN=gitlab_users,OU=AccessGroups,OU=*OU где искать пользователей*,DC=*имя-*,DC=*-вашего-,DC=*-домена*)’)

После добавления этого нужно сделать 3 действия:

1. gitlab-ctl reconfigure — реконфигурируем гитлаб. должно пройти без ошибок

2. gitlab-rake gitlab:ldap:check — проверим работу ldap подключения. Должно пройти без ошибок и показать только те учетки, которые могут авторизоваться (входят в соответствующую группу в AD).

3. перезагрузить виртуалку. Ну или перезапустить сервис gitlab (gitlab-ctl restart). у меня без этого в веб интерфейсе не появлялась вкладка. после перезапуска сервиса нужно подождать немного, пока не переподнимется сервер приложений а то nginx отдает 502

Потом выключаем возможность самостоятельной регистрации в сервисе (sign-up)

Admin Area > Settings > Sign-up Restrictions — убрать галочку с Sign-Up enabled

Первичная настройка завершена- дальше только настройка логики через веб интерфейс!

П.С. Особо хочу отметить — CE версия не умеет матчить в базу группы из AD. Поэтому кто там есть кто (юзер, админ и пр) — придется вручную определять внутри самого gitlab. При первом логине AD пользователя, создается локальный матчинг в базе пользователей Gitlab — подтягивается логи, фио, имейл, пароль и пр. После этого через админку самого gitlab юзера можно запихивать в группу.

Оговорюсь сразу — исторически сложилось так, что местом хранения резервных копий в этом проекте является Windows File share ( Виндовая файлопомойка — говоря по русски). Отказываться от этого решения никто не хотел, моей задачей было его поддержать. В Вашем случае коллеги, можно выбрать что угодно иное!

Резервное копирование устроено просто:

1. На файлсервере, выполняющем роль хранилища бекапов сделана файлшара, специально под git сервер

2. На самом сервере установлен veeam agent for linux для бекапа самой виртуалки «на горячую» — на случай краха сервера

3. Плюс сделан скрипт который бекапит конфиги и данные gitlab на случай если вируталка останется живой но пострадают данные (например в результате обновления)

Файл шара:

Хранение бекапов:

Настройка бекапов

В gitlab уже встроен функционал для создания резервных копий: https://docs.gitlab.com/ee/raketasks/backup_restore.html

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

/usr/bin/gitlab-rake gitlab:backup:create STRATEGY=copy

плюс выполняющий дополнительные действия.
Конфигурация самого gitlab движка для создания бекапов так, как надо нам (файл /etc/gitlab/gitlab.rb):

gitlab_rails[‘backup_upload_connection’] = {
:provider => ‘Local’,
:local_root => ‘/home/backup’
}

# The directory inside the mounted folder to copy backups to
# Use ‘.’ to store them in the root directory
gitlab_rails[‘backup_upload_remote_directory’] = ‘gitlab_backups’
gitlab_rails[‘backup_archive_permissions’] = 0644

Скрипт лежит по пути:

root@git:~# ls -l /home/scripts/git_backup.sh
-rwxr-xr-x 1 root root 3961 ноя 4 17:51 /home/scripts/git_backup.sh

и запускается cron задачей (уж простите но логины, пароли и прочее я тут подтер)

root@git:~# crontab -l

# резервное копирование данных гитлаба
0 1 * * * /home/scripts/git_backup.sh gitlab /etc/gitlab /home/backup //win-fs01.*имя сервера*/git/data-backup (backup USER) (backup password) &>/var/log/git-backup.log

Лог бекапа выглядит таким образом:

root@git:~# cat /var/log/git-backup.log
Starting backup of [/etc/gitlab] folder to [//win-fs01.*имя сервера*/git/data-backup]
* [Mount smb share] — Done!
* [Test write access] — Done!
* [Backup config files] — Done!
* [Test backup archive] — Done!
Dumping database …
Dumping PostgreSQL database gitlabhq_production … [DONE]
done
Dumping repositories …
done
Dumping uploads …
done
Dumping builds …
done
Dumping artifacts …
done
Dumping pages …
done
Dumping lfs objects …
done
Dumping container registry images …
[DISABLED]
Creating backup archive: 1541357698_2018_11_04_11.4.4_gitlab_backup.tar … done
Uploading backup archive to remote storage gitlab_backups … done
Deleting tmp directories … done
done
done
done
done
done
done
done
Deleting old backups … skipping
* [Backup GitLab data via internal backup tool] — Done!
* [Check and delete old backups] — Done!
* [Unmount smb share] — Done!
: backup job [gitlab] done successfully.

Текст скрипта:

#!/bin/bash
#
### Description: Script for static files backup.
### This version is Ubuntu server 16.04 compatible.
### Version: 0.1
### Written by: Kirill Kazarin, Russia, SPB, 06-2018 — [email protected]
### Usage: bash *scriptname* task_name backup_source_dir mount_folder smb_share_destination smb_user smb_password
### Example: bash file_backup.sh wiki /home/data /home/backup //192.168.100.1/backup_test kirill Qwerty.123

TASK_NAME=»$1″
SOURCE_DIR=»$2″
MOUNT_DIR=»$3″
SMB_SHARE=»$4″
SMB_USER=»$5″
SMB_PASSWD=»$6″
LOG_FILE=»backup.log»
BACKUP_DATE=$(date +»%m-%d-%y»)
BACKUP_FILE=»$MOUNT_DIR»/cfg/etc_»$TASK_NAME»-backup-«$BACKUP_DATE».tar.gz
BACKUP_AGE=7 # delete files older that this value

## check result of operation
operation_result()
{
# arguments:
# $1 — return code
# $2 — action name

if [ ! «$1″ -eq 0 ]; then
printf » * There was a problem during [%s] \nSee [%s] for more information!\n» «$2» «$LOG_FILE»
printf «%s: backup job %s failed.\n» «$BACKUP_DATE» «$TASK_NAME» >> «$LOG_FILE»
exit 1
fi
printf » * [%s] — Done!\n» «$2» | tee -a «$LOG_FILE»
}

## Check that script running with root privileges
if [ «$EUID» -ne 0 ]; then
printf «Use root account for backup! \n»
exit 1
fi

## Check that user don’t forget about all arguments
if [ «$#» -ne 6 ]; then
printf «Illegal number of parameters \nParameters: task_name, source_directory, mount_point, smb_share_addr, smb_user, smb_password!\n»
exit 1
else
printf «Starting backup of [%s] folder to [%s]\n» «$SOURCE_DIR» «$SMB_SHARE» | tee -a «$LOG_FILE»
fi

## Check if a source (backup) directory does not exist
if [ ! -d «$SOURCE_DIR» ]
then
printf «Directory [%s] DOES NOT exists!\n» «$SOURCE_DIR» | tee -a «$LOG_FILE»
exit 1
fi


## Checking that cifs-utils package installed
DEP=»$(which mount.cifs | wc -l)»
if [ «$DEP» -ne 1 ]; then
printf » * cifs-utils package not installed!\n» | tee -a «$LOG_FILE»
exit 1
fi

## Check that smb share already mounted. If not — mount it!
if [[ $(findmnt -M «$MOUNT_DIR») ]]; then
printf » * [%s] already mounted, continue…\n» «$MOUNT_DIR» | tee -a «$LOG_FILE»
else
## Mount smb share for backup
mount -t cifs «$SMB_SHARE» «$MOUNT_DIR» —verbose -o username=»$SMB_USER»,password=»$SMB_PASSWD»,uid=git,file_mode=0660,dir_mode=0775&>> «$LOG_FILE»
operation_result $? «Mount smb share»
fi

## Check that we can write into this folder and delete this file
echo «Test_1234567890_string.» &>> «$LOG_FILE» > «$MOUNT_DIR»/test.txt \
&& rm «$MOUNT_DIR»/test.txt &>> «$LOG_FILE»
operation_result $? «Test write access»

## start backup process
tar -czf «$BACKUP_FILE» «$SOURCE_DIR» &>> «$LOG_FILE»
operation_result $? «Backup config files»

## check archive after backup
tar tzf «$BACKUP_FILE» &> /dev/nul
if [ ! «$?» -eq 0 ]; then
printf » * [Test backup archive] — failed!\n» | tee -a «$LOG_FILE»

## Unmount smb share
umount «$MOUNT_DIR» &>> «$LOG_FILE»
operation_result $? «Unmount smb share»

exit 1

else
printf » * [Test backup archive] — Done!\n» | tee -a «$LOG_FILE»

fi

## Create gitlab backup
/usr/bin/gitlab-rake gitlab:backup:create STRATEGY=copy | tee -a «$LOG_FILE»
operation_result $? «Backup GitLab data via internal backup tool»

## Delete old backups
find «$MOUNT_DIR» -mtime +»$BACKUP_AGE» -type f -delete &>> «$LOG_FILE»
operation_result $? «Check and delete old backups»

## Unmount smb share
umount «$MOUNT_DIR» &>> «$LOG_FILE»
operation_result $? «Unmount smb share»

## writes results in log
printf «%s: backup job [$TASK_NAME] done successfully.\n» | tee -a «$LOG_FILE»

exit 0

Как видно из листинга, скрипт делает ряд шагов:

• Проверяет все что нужно ему для работы ( права, установленное ПО, набор аргументов)
• Проверяет не смонтирована ли уже файл-шара, если нет то монтирует ее иначе шаг пропускается
• Тестируем возможность записать что-то на файл-шару
• Делает своими средствами бекап конфигурации GitLab
• Использует механизм Gitlab для резервного копирования
• Удаляет старые бекапы ( по умолчанию все что старше 7 дней)
• Размонтирует файл шару

Параллельно скрипт ведет полный лог действий.

Надеюсь статья была Вам полезна, коллеги!

Как настроить Git-сервер на Linux

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

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

В этой статье мы объясним, как настроить пустой сервер Git в Linux. Эта настройка хороша, если у вас мало репозиториев, а соавторы технически подкованы. В противном случае вам следует рассмотреть возможность установки самостоятельно размещенного git-приложения, такого как Gitea, Gogs или Gitlab.

Сервер Git может быть установлен на любой удаленной машине с Linux или даже в вашей локальной системе.

Настройка Git-сервера

Первым шагом является установка Git на ваш сервер.

Если вы используете Debian или Ubuntu, обновите индекс локального пакета и установите git , выполнив следующие команды от имени пользователя sudo:

sudo apt update && sudo apt install git

Чтобы установить пакет git на серверах CentOS, введите:

sudo yum install git

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

sudo useradd -r -m -U -d /home/git -s /bin/bash git

Домашний каталог пользователя установлен в /home/git. Все репозитории будут храниться в этом каталоге. Мы не установили пароль для пользователя «git», вход в систему будет возможен только с использованием ключей ssh.

Переключитесь на пользователя «git» с помощью команды su:

sudo su - git

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

mkdir -p ~/.ssh && chmod 0700 ~/.ssh

Создайте файл с именем ~/.ssh/authorized_keys, который будет содержать ключи SSH авторизованных пользователей:

touch ~/.ssh/authorized_keys && chmod 0600 ~/.ssh/authorized_keys

Вот и все. Настройка сервера завершена. Теперь вы готовы создать свой первый Git-репозиторий.

Запустите следующую команду, чтобы запустить новый пустой репозиторий:

git init --bare ~/projectname.git

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

Initialized empty Git repository in /home/git/projectname.git/

Настройка локального Git-репозитория

Чтобы иметь возможность отправлять локальные изменения git на сервер Git, вы должны добавить свой открытый SSH-ключ локального пользователя в файл authorized_keys удаленного пользователя «git» .

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

cat ~/.ssh/id_rsa.pub

Вывод должен выглядеть примерно так:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDd/mnMzHwjUzK8g3ldfsfRpJuC16mhWamaXRk8ySQrD/dzpbRLfDnZsLxCzRoq+ZzFHGwcQlJergtergdHGRrO8FE5jl3IWRRp+mP12qYw== [email protected]

Если вы получаете сообщение об ошибке: No such file or directory, означающее, что у вас нет пары ключей SSH, созданной на вашем локальном компьютере.

Для создания новой пары ключей SSH используйте следующую команду:

ssh-keygen -t rsa -b 4096 -C "[email protected]"

Скопируйте вывод catкоманды выше и вернитесь в консоль Git-сервера.

На сервере откройте текстовый редактор и вставьте в файл ~/.ssh/authorized_keys открытый ключ, скопированный с локального компьютера:

sudo nano /home/git/.ssh/authorized_keys

Весь текст открытого ключа должен быть в одной строке.

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

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

cd /path/to/local/project

Инициализировать репозиторий git:

git init .

Последний шаг – добавить git remote в ваш локальный репозиторий:

git remote add origin git@git_server_ip:projectname.git

Не забудьте заменить git_server_ip на ваше имя хоста Git-сервера или IP-адрес.

Чтобы убедиться, что все настроено правильно, создайте тестовый файл :

touch test_file

Добавьте изменения в область подготовки:

git add .

Зафиксируйте изменения:

git commit -m "descriptive message"

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

git push -u origin master

Если все настроено правильно, вывод должен выглядеть примерно так:

Counting objects: 3, done.
Writing objects: 100% (3/3), 218 bytes | 218.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To git_server_ip:projectname.git
 * [new branch]      master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.

Чтобы добавить нового соавтора, просто скопируйте его открытый SSH-ключ в файл ~/.ssh/authorized_keys пользователя «git» .

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

Заключение

В этой статье мы показали, как настроить свой собственный Git-сервер и создать репозитории.

Если вы столкнулись с проблемой или у вас есть отзыв, оставьте комментарий ниже.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Свой Git сервер на Windows — aleksandr ● ru

В принципе все это легко нагуглить, но тем не менее опишу свой опыт. Итак, есть windows сервер (в моем случае Windows Server 2008, но все описанное ниже применимо ко всем windows), на этом севере работает некое веб-приложение, которое хочется коллективно развивать командой из нескольких человек. Идеи лучше чем Git в голову не пришло.

Подготовительный этап 

На сервере ставим и настраиваем SSH сервер (в моем случае это оказался Bitvise SSH Server, далее все настройки буду описывать относительно него).

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

Если требуется работать с Git из интернета, также пробрасываем соответствующий порт наружу, обычно это 22, но в моем случае получилось 222 по техническим причинам. Проверяем доступность сервера по SSH снаружи и возможность авторизации с ключом, PuTTY в помощь 🙂

Ставим собственно Git (в моем случае это msysgit). Народ предлагает ставить в короткий путь вроде C:/Git, но я ставил в каталог по-умолчанию, все работает. Через Git GUI создаем репозиторий, в моем случае это С:/Webroot/test-git.

Клиентская часть

В моем случае клиенты — тоже windows машины, на них потребуется Git (тот же msysgit) и клиент TurtoiseGit, в моем случае. На клиенте пытаемся склонировать наш репозиторий при помощи Git Clone, вводим урл

ssh://[email protected]:222/C:/Webroot/test-git 

где mylogin — это ваш логин для ssh, example.com:222 — адрес сервера и порт (не обязательно), C:/Webroot/test-git — полный путь к репозиторию.

Жмем ОК, ждем, получаем ошибку и отправляемся дальше настраивать сервер.

Настройка Git на сервере

Первым делом идем в переменные окружения (Компьютер -> Свойства -> Дополнительные параметры системы -> Переменные среды). В разделе системные переменные находим PATH и жмем изменить. Убеждаемся что там есть, а если нет, то добавляем три папки:

C:\Program Files (x86)\Git\cmd;C:\Program Files (x86)\Git\bin;C:\Program Files (x86)\Git\libexec\git-core 

На всякий случай напомню, что Git у нас стоит в C:\Program Files (x86)\Git.

Теперь проверяем, что Git доступен. Либо пытаемся еще раз Git Clone на клиенте и получаем другую ошибку, либо заходим по ssh и говорим git прямо и текущей папки, получаем краткий хелп от гита. Если ругается на неизвестную команду, ищем ошибку на предыдущем шаге.

Теперь наша проблема (если посмотреть логи ssh сервера) заключается в том, что git-upload-pack на вход получает путь, обернутый в одинарные кавычки, и естественно, не работает. Нормального решения нет, но есть подпорки, например как описано здесь. Моя версия проделанного:

Создаем файл

C:\Program Files (x86)\Git\cmd\gitcmdhelper.sh 

прописываем в него

$*


Идем в настройки ssh сервера и для нужного пользователя (или группы) изменяем параметр Exec request prefix на

cmd.exe /c sh gitcmdhelper.sh 

ВНИМАНИЕ! после .sh есть пробел! Строка получается вот такая «cmd.exe /c sh gitcmdhelper.sh «, без пробела на конце не будет работать!

Замечание. Эта подпорка лишает вас возможности работать с путями в которых есть пробелы, в большинстве случаев это не критично, но все же.

В глобальном конфиге Git вносим следующие изменения (как советуют на хабре), правим C:\Program Files (x86)\Git\etc\gitconfig

[core]
symlinks = false
autocrlf = true
ignorecase = true
quotepath = false
[i18n]
commitencoding = cp1251
logoutputencoding = cp1251

И, о чудо! Оно теперь работает! Ну по крайней мере мне удалось сделать Pull, Commit и Push.

И последнее — хуки

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

Итак у нас есть bare-репозиторий C:\Webroot\test-git в который приходят все комиты и пуши, и рабочая копия C:\Webroot\test-git.production, на которую настроен document root сервера.

Рабочая копия должна быть «настроена на» bare-репозиторий, для этого в рабочей копии выполним команду

git remote add local C:/Webroot/test-git 

результатом станет добавление в  C:\Webroot\test-git.production\.git\config следующего

...
[remote "local"]
url = C:/Webroot/test-git
fetch = +refs/heads/*:refs/remotes/local/*  

Для того чтоб заработали хуки, нужно положить файл с названием действия в папку в bare-репозитории .git/hooks/, в нашем случае это будет

C:\Webroot\test-git\.git\hooks\post-receive

обычно там уже заложен post-receive.sample, его достаточно просто переименовать. А в сам файл вписываем следующее содержимое, которое после получения данных заставит рабочую копию сделать pull:

unset GIT_DIR
cd C:/Webroot/test-git.production
git pull local master

Таким образом мы будем корректно обновлять рабочую копию при каждом push-е в bare-репозиторий.

Вот пара полезных ссылок по теме:

P.S.

Поднимать Git на windows, по моему мнению, не самое лучшее решение, если есть возможность все же лучше это сделать на Linux.

Git — Book

2nd Edition (2014)

Download Ebook

The entire Pro Git book, written by Scott Chacon and Ben Straub and published by Apress, is available here. All content is licensed under the Creative Commons Attribution Non Commercial Share Alike 3.0 license. Print versions of the book are available on Amazon.com.>

1. 1. 1.1
      О системе контроля версий
   2. 1.2
      Краткая история Git
   3. 1.3
      Основы Git
   4. 1.4
      Командная строка
   5. 1.5
      Установка Git
   6. 1.6
      Первоначальная настройка Git
   7. 1.7
      Как получить помощь?
   8. 1.8
      Заключение
2. 1. 2.1
      Создание Git-репозитория
   2. 2.2
      Запись изменений в репозиторий
   3. 2.3
      Просмотр истории коммитов
   4. 2.4
      Операции отмены
   5. 2.5
      Работа с удалёнными репозиториями
   6. 2.6
      Работа с метками
   7. 2.7
      Псевдонимы в Git
   8. 2.8
      Заключение

3. 3.

Git — книга

2-е издание (2014)

Загрузить электронную книгу

Вся книга Pro Git, написанная Скоттом Чаконом и Беном Штраубом и опубликованная Apress, доступна здесь. Все содержимое находится под лицензией Creative Commons Attribution Non Commercial Share Alike 3.0. Печатные версии книги доступны на Amazon.com.>

1. 1. 1.1
      О контроле версий
   2. 1.2
      Краткая история Git
   3. 1.3
      Что такое Git?
   4. 1.4
      Командная строка
   5. 1.5
      Установка Git
   6. 1.6
      Первоначальная настройка Git
   7. 1.7
      Получать помощь
   8. 1,8
      Резюме
2. 1. 2.1
      Получение репозитория Git
   2. 2.2
      Запись изменений в репозиторий
   3. 2.3
      Просмотр истории фиксации
   4. 2.4
      Отмена вещей
   5. 2,5
      Работа с пультами
   6. 2,6
      Теги
   7. 2,7
      Псевдонимы Git
   8. 2,8
      Резюме
3. 1. 3.1
      Ветки в двух словах
   2. 3.2
      Базовое ветвление и слияние
   3. 3.3
      Управление филиалом
   4. 3,4
      Ветвление рабочих процессов
   5. 3.5
      Удаленные филиалы
   6. 3,6
      Ребазинг
   7. 3,7
      Резюме
4. 1. 4.1
      Протоколы
   2. 4.2
      Получение Git на сервере
   3. 4.3
      Создание открытого ключа SSH
   4. 4.4
      Настройка сервера
   5. 4.5
      Git Daemon
   6. 4.6
      Умный HTTP
   7. 4.7
      GitWeb
   8. 4.8
      GitLab
   9. 4.9
      Сторонние варианты размещения
   10. 4.10
       Резюме
5. 1. 5.1
      Распределенные рабочие процессы
   2. 5.2
      Вклад в проект
   3. 5.3
      Сопровождение проекта
   4. 5,4
      Резюме
6. 1. 6.1
      Настройка и конфигурация учетной записи
   2. 6.2
      Вклад в проект
   3. 6.3
      Сопровождение проекта
   4. 6.4
      Управление организацией
   5. 6.5
      Создание сценариев на GitHub
   6. 6,6
      Резюме
7. 1. 7.1
      Выбор редакции
   2. 7.2

.

Git — книга

2-е издание (2014)

Загрузить электронную книгу

Вся книга Pro Git, написанная Скоттом Чаконом и Беном Штраубом и опубликованная Apress, доступна здесь. Все содержимое находится под лицензией Creative Commons Attribution Non Commercial Share Alike 3.0. Печатные версии книги доступны на Amazon.com.>

1. 1. 1.1
      О контроле версий
   2. 1.2
      Краткая история Git
   3. 1.3
      Что такое Git?
   4. 1.4
      Командная строка
   5. 1.5
      Установка Git
   6. 1.6
      Первоначальная настройка Git
   7. 1.7
      Получать помощь
   8. 1,8
      Резюме
2. 1. 2.1
      Получение репозитория Git
   2. 2.2
      Запись изменений в репозиторий
   3. 2.3
      Просмотр истории фиксации
   4. 2.4
      Отмена вещей
   5. 2,5
      Работа с пультами
   6. 2,6
      Теги
   7. 2,7
      Псевдонимы Git
   8. 2,8
      Резюме
3. 1. 3.1
      Ветки в двух словах
   2. 3.2
      Базовое ветвление и слияние
   3. 3.3
      Управление филиалом
   4. 3,4
      Ветвление рабочих процессов
   5. 3.5
      Удаленные филиалы
   6. 3,6
      Ребазинг
   7. 3,7
      Резюме
4. 1. 4.1
      Протоколы
   2. 4.2
      Получение Git на сервере
   3. 4.3
      Создание открытого ключа SSH
   4. 4.4
      Настройка сервера
   5. 4.5
      Git Daemon
   6. 4.6
      Умный HTTP
   7. 4.7
      GitWeb
   8. 4.8
      GitLab
   9. 4.9
      Сторонние варианты размещения
   10. 4.10
       Резюме
5. 1. 5.1
      Распределенные рабочие процессы
   2. 5.2
      Вклад в проект
   3. 5.3
      Сопровождение проекта
   4. 5,4
      Резюме
6. 1. 6.1
      Настройка и конфигурация учетной записи
   2. 6.2
      Вклад в проект
   3. 6.3
      Сопровождение проекта
   4. 6.4
      Управление организацией
   5. 6.5
      Создание сценариев на GitHub
   6. 6,6
      Резюме
7. 1. 7.1
      Выбор редакции
   2. 7.2

.

Git — книга

2-е издание (2014)

Загрузить электронную книгу

Вся книга Pro Git, написанная Скоттом Чаконом и Беном Штраубом и опубликованная Apress, доступна здесь. Все содержимое находится под лицензией Creative Commons Attribution Non Commercial Share Alike 3.0. Печатные версии книги доступны на Amazon.com.>

1. 1. 1.1
      Il Controllo di Versione
   2. 1.2
      Una Breve Storia di Git
   3. 1.3
      Cos’é Git?
   4. 1.4
      La riga di comando
   5. 1.5
      Установка Git
   6. 1.6
      Первоначальная настройка Git
   7. 1.7
      Chiedere aiuto
   8. 1,8
      Соммарио
2. 1. 2.1
      Получение репозитория Git
   2. 2.2
      Запись изменений в репозиторий
   3. 2.3
      Просмотр истории фиксации
   4. 2.4
      Отмена вещей
   5. 2,5
      Работа с пультами
   6. 2,6
      Теги
   7. 2,7
      Псевдонимы Git
   8. 2,8
      Резюме
3. 1. 3.1
      Ветки в двух словах
   2. 3.2
      Базовое ветвление и слияние
   3. 3.3
      Управление филиалом
   4. 3,4
      Ветвление рабочих процессов
   5. 3.5
      Удаленные филиалы
   6. 3,6
      Ребазинг
   7. 3,7
      Резюме
4. 1. 4.1
      Протоколы
   2. 4.2
      Получение Git на сервере
   3. 4.3
      Создание открытого ключа SSH
   4. 4.4
      Настройка сервера
   5. 4.5
      Git Daemon
   6. 4.6
      Умный HTTP
   7. 4.7
      GitWeb
   8. 4.8
      GitLab
   9. 4.9
      Сторонние варианты размещения
   10. 4.10
       Резюме
5. 1. 5.1
      Распределенные рабочие процессы
   2. 5.2
      Вклад в проект
   3. 5.3

.

Настройка Git — GitHub Docs

Документы GitHub

• Все продукты

• GitHub.com

• Начиная

  • Быстрый старт
    • Настроить Git
    • Создать репо
    • Форк репо
    • Быть социальным
  • Изучение GitHub
    • Продукты GitHub
    • Изучение выпусков раннего доступа с предварительным просмотром функций
    • Типы аккаунтов GitHub
    • Часто задаваемые вопросы об изменениях в планах GitHub
    • GitHub CLI
    • GitHub Desktop
    • GitHub для мобильных устройств
    • Разрешения на доступ на GitHub
    • Глоссарий GitHub
    • Шпаргалка по Git
    • Учебные ресурсы Git и GitHub
  • Регистрация на GitHub
    • Регистрация новой учетной записи GitHub
    • Подтверждение адреса электронной почты
    • Настройка пробной версии GitHub Enterprise Cloud
    • Настройка пробной версии GitHub Enterprise Server
  • Изучение проектов на GitHub
    • Поиск способов внести свой вклад в открытый исходный код на GitHub
    • Сохранение репозиториев со звездочками

.