KAZARIN OnLine
Blog about IT, Me, education, etc…
Введение в DevOps: Как пользоваться Git (на примере Gitlab)
Добрый день! Данная статья представляет собой краткий мануал как пользоваться Git в производственной среде. В прошлой статье я уже упоминал про развертывание Gitlab сервера внутри компании, считайте эту статью — продолжением.
Откуда черпать информацию:
Поставить Git можно на любую ОС — консольные и графические клиенты есть под любую операционку.
Мое имхо — использование графических клиентов излишне, мне хватает консольного клиента, тем более в сети большинство примеров про него. Но если что — клиенты встроены во все популярные IDE.
Основные команды
Что надо обязательно знать и уметь использовать (я привожу их в случайном порядке):
Подготовка к работе
Итак, дорогой друг, ты решил попробовать эту странную штуку под названием Git, хотя ни разу ей не пользовался — погнали!
1. Сгенерируй себе ssh ключ.
Я понятия не имею какой ОС ты пользуешься так что загугли как это сделать (да, я даже облегчил тебе задачу). Я использую Linux, у меня он уже есть.
2. Настрой свой git клиент. Для этого есть опции config. Мне хватает 4-х:
Кстати, когда ты пользуешься опцией global — ты задаешь настройку для клиента глобально (кеп), а если ты введешь такие же команды в конкретном репозитории — ты настроишь параметры только для него.
3. Иди в Gitlab через веб интерфейс (либо публичный, либо свой, если разворачивали) и там заходи со своей учеткой. И да если ты пользуешься своим Gitlab серверов, как это было в прошлой статье, не забудь выбрать вкладку LDAP:
Настройка учетки в Gitlab
Надеюсь ты смог залогиниться.
Далее идем в настройки профиля (https://гит-сервер/profile):
Там настраиваем себе язык, цвет темы, цвет редактора, аватарку, черта лысого — развлекайся.
Главное- потом не забудь зайти в пункт SSH ключи (https://гит-сервер/profile/keys) и там добавить хотя бы 1 (но только публичную часть):
(если что, я тут сократил ключ чтобы весь не вставлять)
Плюс советую поиграться с настройкой тем и редактора: https://гит-сервер/profile/preferences
И настроить дефолтный дашборд:
Создание репозитория
Давай рассмотрим создание репозитория на примере репы для бекап-скриптов. Для этого я сделал отдельный неймспейс/группу OPS (Operations)
и теперь создадим тут сначала подгруппу (New Subgroup) а потом проект (New Project). Проект это и есть репозиторий. А группу я хочу сделать для большей гранулированности — чтобы скрипты для бекапов были в подгруппе «backups». Ну так выглядит симпатичней и навигация проще имхо.
Итак, мы получаем страничку пустого проекта (сиречь репозитория):
где нам не двусмысленно подсказывают как мы можем начать работу. Такая подсказка будет появляться у вас на экране КАЖДЫЙ раз при создании пустого проекта и висеть там ДО ТЕХ ПОР пока вы хоть 1 файл в проект не зальете. Так что не надо себе сохранять как памятку:
Пример работы с репозиторием
Подготовка
Итак, для примера у меня есть папка test в которой лежат пара скриптов для бекапа файлов — я хочу запихнуть их в этот репозиторий, инициировав его. Итак, что на входе:
Я не хочу чтобы в репозиторий попадали всякие мусорные файлы, как например скрытая папка «.directory», как тут. Для этого я делаю файл «.gitignore» в который вношу имена и маски имен объектов (файлов и каталогов) которые должны игнорироваться git-ом:
Инициализация и первый коммит
Теперь воспользуемся инструкцией из второго примера на нашей страничке пустого проекта «Existing folder»:
Теперь разберем по пунктам что я сделал:
Смотрим результат
Итак, возвращаемся в Web интерфейс гитлаба и что мы там видим:
Создание веток и слияние
В гите есть понятие веток — это одна из основополагающих концепций и вам ПРИДЕТСЯ ее узнать и полюбить.
Основная идея такова — есть главная ветка, которую обычно зовут «мастер» и ряд других. Например «develop», «staging» и пр. В ряде случаев для имени ветки выбирается имя фичи или изменения над которым в ней работают. Когда разработчик хочет внести изменение в код — он должен «ответвиться» от мастера, поработать, внести свои наработки в свою ветку репозитория, протестировать их и только убедившись что все хорошо (хорошей практикой является демонстрация этих наработок и их тестирования коллегам) — «влить» изменения из своей ветки в мастер.
Такой подход зовется Git Flow и выглядит примерно вот так:
Его мы сейчас и попробуем реализовать (Правда в одно лицо, но для групповой работы схема будет примерно такой же). Мы забыли добавить очень важный файл, который должен являться неизменным атрибутом каждого репозитория — файл README. Как и все git хостинги, Gitlab ищет в каталоге репозитория этот файл и если находит- показывает его содержимое на главной странице репозитория сразу под списком файлов. Gitlab понимаем и умеет рендерить разметку markdown, правда с некоторыми своими условностями, поэтому советую почитать их документацию.
Если Вам лень учить синтаксис или ставить локальный редактор makrdown, или искать плагин к свой ide, воспользуйтесь вот этим сервисом — stackedit.io
Добавим простой файл Readme в котором опишем содержимое проекта:
Import your project from GitHub to GitLab
Using the importer, you can import your GitHub repositories to GitLab.com or to your self-managed GitLab instance.
References to pull requests and issues are preserved (GitLab.com & 8.7+), and each imported repository maintains visibility level unless that visibility level is restricted, in which case it defaults to the default project visibility.
This process does not migrate or import any types of groups or organizations from GitHub to GitLab.
Use cases
How it works
When issues and pull requests are being imported, the importer attempts to find their GitHub authors and assignees in the database of the GitLab instance (note that pull requests are called “merge requests” in GitLab).
Have a GitHub account with a public-facing email address that matches their GitLab account’s email address.
If a user referenced in the project is not found in the GitLab database, the project creator (typically the user that initiated the import process) is set as the author/assignee, but a note on the issue mentioning the original GitHub author is added.
The importer creates any new namespaces (groups) if they do not exist, or, if the namespace is taken, the repository is imported under the namespace of the user who initiated the import process. The namespace/repository name can also be edited, with the proper permissions.
For additional technical details, you can refer to the GitHub Importer developer documentation.
For an overview of the import process, see the video Migrating from GitHub to GitLab.
Import your GitHub repository into GitLab
Use the GitHub integration
User-matching attempts occur in that order, and if a user is not identified either way, the activity is associated with the user account that is performing the import.
Use a GitHub token
To use a newer personal access token in imports after previously performing these steps, sign out of your GitLab account and sign in again, or revoke the older personal access token in GitHub.
Select which repositories to import
Mirror a repository and share pipeline status
Depending on your GitLab tier, repository mirroring can be set up to keep your imported repository in sync with its GitHub copy.
Additionally, you can configure GitLab to send pipeline status updates back GitHub with the GitHub Project Integration.
If you import your project using CI/CD for external repository, then both of the above are automatically configured.
Improve the speed of imports on self-managed instances
For an optimal experience, it’s recommended having at least 4 Sidekiq processes (each running a number of threads equal to the number of CPU cores) that only process these queues. It’s also recommended that these processes run on separate servers. For 4 servers with 8 cores this means you can import up to 32 objects (for example, issues) in parallel.
Reducing the time spent in cloning a repository can be done by increasing network throughput, CPU capacity, and disk performance (by using high performance SSDs, for example) of the disks that store the Git repositories (for your GitLab instance). Increasing the number of Sidekiq workers does not reduce the time spent cloning repositories.
Alternative way to import notes and diff notes
An alternative approach for importing notes and diff notes is available behind a feature flag.
To use the alternative way of importing notes, the github_importer_single_endpoint_notes_import feature flag must be enabled on the group project is being imported into.
Reduce GitHub API request objects per page
Some GitHub API endpoints may return a 500 or 502 error for project imports from large repositories. To reduce the chance of such errors, you can enable the feature flag github_importer_lower_per_page_limit in the group project importing the data. This reduces the page size from 100 to 50.
To enable this feature flag, start a Rails console and run the following enable command:
To disable the feature, run this command:
Automate group and project import
For information on automating user, group, and project import API calls, see Automate group and project import.
Git для новичков (часть 1)
Что такое Git и зачем он нужен?
С помощью Git-a вы можете откатить свой проект до более старой версии, сравнивать, анализировать или сливать свои изменения в репозиторий.
Репозиторием называют хранилище вашего кода и историю его изменений. Git работает локально и все ваши репозитории хранятся в определенных папках на жестком диске.
Так же ваши репозитории можно хранить и в интернете. Обычно для этого используют три сервиса:
Как работает
В итоге получается очень простой граф, состоящий из одной ветки ( main ) и четырех commit. Все это может превратиться в более сложный граф, состоящий из нескольких веток, которые сливаются в одну.
Об этом мы поговорим в следующих статьях. Для начала разберем работу с одной веткой.
Установка
Основой интерфейс для работы с Git-ом является консоль/терминал. Это не совсем удобно, тем более для новичков, поэтому предлагаю поставить дополнительную программу с графическим интерфейсом (кнопками, графиками и т.д.). О них я расскажу чуть позже.
Но для начала, все же установим сам Git.
Windows. Проходим по этой ссылке, выбираем под вашу ОС (32 или 64 битную), скачиваем и устанавливаем.
Для Mac OS. Открываем терминал и пишем:
Linux. Открываем терминал и вводим следующую команду.
Настройка
Вы установили себе Git и можете им пользоваться. Давайте теперь его настроим, чтобы когда вы создавали commit, указывался автор, кто его создал.
Открываем терминал (Linux и MacOS) или консоль (Windows) и вводим следующие команды.
Создание репозитория
Теперь вы готовы к работе с Git локально на компьютере.
Создадим наш первый репозиторий. Для этого пройдите в папку вашего проекта.
Теперь Git отслеживает изменения файлов вашего проекта. Но, так как вы только создали репозиторий в нем нет вашего кода. Для этого необходимо создать commit.
Отлично. Вы создали свой первый репозиторий и заполнили его первым commit.
Процесс работы с Git
Не стоит после каждого изменения файла делать commit. Чаще всего их создают, когда:
Создан новый функционал
Добавлен новый блок на верстке
Исправлены ошибки по коду
Вы завершили рабочий день и хотите сохранить код
Это поможет держать вашу ветки в чистоте и порядке. Тем самым, вы будете видеть историю изменений по каждому нововведению в вашем проекте, а не по каждому файлу.
Визуальный интерфейс
Как я и говорил ранее, существуют дополнительные программы для облегчения использования Git. Некоторые текстовые редакторы или полноценные среды разработки уже включают в себя вспомогательный интерфейс для работы с ним.
Но существуют и отдельные программы по работе с Git. Могу посоветовать эти:
Я не буду рассказывать как они работают. Предлагаю разобраться с этим самостоятельно.
Создаем свой первый проект и выкладываем на GitHub
Давайте разберемся как это сделать, с помощью среды разработки Visual Studio Code (VS Code).
Перед началом предлагаю зарегистрироваться на GitHub.
Создайте папку, где будет храниться ваш проект. Если такая папка уже есть, то создавать новую не надо.
Установите себе дополнительно анализаторы кода для JavaScript и PHP
Откройте вашу папку, которую создали ранее
После этого у вас появится вот такой интерфейс
Здесь будут располагаться все файлы вашего проекта
Здесь можно работать с Git-ом
Кнопка для создания нового файла
Кнопка для создания новой папки
Давайте теперь перейдем во вкладу для работы с Git-ом.
Откроется вот такое окно:
Кнопка для публикации нашего проекта на GitHub
Вы создали и опубликовали репозиторий на GitHub.
Теперь сделаем изменения в коде и попробуем их снова опубликовать. Перейдите во вкладку с файлами, отредактируйте какой-нибудь файл, не забудьте нажать crtl+s (Windows) или cmd+s (MacOS), чтобы сохранить файл. Вернитесь обратно во вкладу управления Git.
Если посмотреть на значок вкладки Git, то можно увидеть цифру 1 в синем кружке. Она означает, сколько файлов у нас изменено и незакоммичено. Давайте его закоммитим и опубликуем:
Кнопка для просмотра изменений в файле. Необязательно нажимать, указал для справки
Добавляем наш файл для будущего commit
Отправляем наш commit в GitHub
Поздравляю, вы научились создавать commit и отправлять его в GitHub!
Это первая вводная статья по утилите Git. Здесь мы рассмотрели:
Как его устанавливать
Как его настраивать
Как инициализировать репозиторий и создать commit через консоль
Как на примере VS Code, опубликовать свой код на GitHub
Забегая вперед, советую вам погуглить, как работают следующие команды:
P.S. Для облегчения обучения, оставлю вам ссылку на бесплатный тренажер по Git.
Как работать с GitLab
Сегодня поговорим об азах взаимодействия с одной из самых популярных git-систем.
Что такое GitLab
Сейчас почти никто не пишет код в одиночку. Команды инженеров и разработчиков растут, как на дрожжах. Работая в группах, программисты используют системы управления исходным кодом на базе git, специального инструмента, позволяющего хранить данные разрабатываемого проекта в сети и совместно редактировать его с учетом определенных правил и методик взаимодействия. Самый известный подобный сервис – GitHub. А GitLab – это его собрат, выполняющий те же функции, но устроенный несколько иначе.
GitLab позволяет управлять репозиториями с кодом, отслеживать ошибки в разрабатываемых программах, публиковать код и тестировать его. Это незаменимый инструмент для каждого, кто программирует не в одиночку.
Разница между GitLab и GitHub
Оба сервиса – системы управления репозиториями на базе git. Принципиальных отличий между ними нет. GitHub появился раньше и стал чуть ли не синонимом git, поэтому он популярнее и для многих является единственной системой для управления репозиториями.
Но GitLab есть что предложить с точки зрения функциональности, поэтому все чаще наблюдается переход пользователей с GitHub на GitLab. В частности, это касается разработчиков-новичков, которые пока еще не «приросли» к GitHub.
В связи с растущей популярностью GitLab я и решил познакомить вас с этим сервисом поближе.
Инструкция по использованию GitLab
Перед началом работы с сервисом, нужно создать учетную запись. Процедура эта весьма тривиальна:
Заходим на официальный сайт GitLab.
В верхнем левом углу находим кнопку Login и жмем по ней.
Через пару секунд перед вам откроется форма входа в систему, а под ней будет ссылка на форму регистрации (Register now). Переходим по ней. 
Заполняем данные для регистрации (классические данные: адрес электронной почты, пароль, логин и т.п.). Жмем на кнопку Register.
В течение пары минут на указанную при регистрации почту «упадет» сообщение со ссылкой для подтверждения создания аккаунта. Переходим по ней. 
Учетная запись готова. Теперь можно переходить непосредственно к знакомству с GitLab.
Как создать проект
Проектом в GitLab считается глобальное рабочее пространство, в котором будет размещен репозиторий с файлами ваших сайтов и приложений. А также в нем можно взаимодействовать с коллегами и использовать другие возможности сервиса.
Поэтому при первом входе под своей учетной записью GitLab попросит вас указать род деятельности, наличие или отсутствие команды, имя рабочей группы и название проекта.
После формирования проекта можно переходить непосредственно к созданию репозиториев, загрузке программ в GitLab и т.п.
Как создать репозиторий
Чтобы воспользоваться репозиторием, нужно создать новый проект:
Кликаем по иконке со значком + в панели управления. 
Выбираем пункт New project/repository. 
Затем кликаем по Create blank project.
Указываем его имя и другие запрашиваемые параметры (можно указать, публичным будет репо или приватным) и нажимаем на кнопку Create Project.
Вместе с проектом сформируется новый git-репозиторий. Теперь можно с ним взаимодействовать, то есть загружать файлы, делать коммиты, создавать различные ветки для разработки продукта и мерджить их при необходимости.
Как загрузить файлы сайта/приложения в GitLab
Первый – используем веб-интерфейс GitLab
На главной странице проекта ищем строку The repository for this project is empty, а под ней кнопку Upload File и нажимаем на нее.
GitLab предложит выбрать файлы проекта для загрузки и последующей работы с ними. Выбираем все файлы, что используем при разработке и выгружаем.
Также можно использовать WebIDE, встроенную в GitLab, чтобы прямо в браузере писать код и создавать файлы для своего приложения/сайта.
Второй – используем командную строку
Тут все сложнее, но на самом GitLab опубликована короткая и доходчивая инструкция по подключению к сервису через командную строку, используя классический git-клиент.
Третий – используем сторонний git-клиент
Существуют приложения в духе Tower и Sublime Merge, позволяющие управлять репозиториями, делать коммиты и пушить изменения в проекты при помощи удобного графического интерфейса. Можно подключиться к GitLab с помощью одной из таких программ.
Как добавить SSH-ключ для подключения к репозиторию
SSH-ключи можно использовать для авторизации в GitLab и для управления репозиториями по протоколу Secure Shell. Чтобы это сделать:
Генерируем ключ с помощью команды ssh-keygen (вводим ее в терминал). 
Генератор предложит сохранить получившийся ключ. Менять директорию, куда сохраняется ключ, необязательно. 
Затем утилита попросит ввести пароль. Его тоже можно не вводить. Просто жмем на Enter. 
Возвращаемся на сайте GitLab. Открываем раздел SSH-keys, вставляем ключ в специально отведенное для этого поле и нажимаем на кнопку Add key. 
Как работать с ветками
Ветки – это инструмент для создания дополнительных вариаций приложения/сайта, которые позволяют вести разработку новых функций, не затрагивая при этом основное приложение, доступное для пользователей.
По умолчанию в GitLab доступна только одна ветка – master. Но ее чаще используют не для разработки, а для публикации готовых сборок проекта, которые нестрашно превратить в релиз для масс.
Поэтому принято создавать новые ветки для разработки дополнительных функций, а уже потом объединять их с основной.
Как создавать ветки
Ветки – не уникальная для GitLab функция. Это часть git, поэтому, как и в случае с репозиториями, тут можно пойти тремя путями:
На сайте GitLab в окне управления репозиторием нажать на кнопку + справа от названия ветки, а потом выбрать пункт New branch в выпадающем меню. 
Или воспользоваться аналогичной функций в используем графическом git-клиенте (Tower, Sublime Merge, GitFox и т.п.).
Любой из способов позволит создавать новую ветку, в которую после этого можно будет отправлять коммиты и делать пуши.
Мерджинг веток
Мерджинг (или объединение) веток – это механизм слияния двух наборов функций одной программы, позволяющий переносить функции из дополнительных веток в основную ветку разработки, где лежит приложение. Результат увидят еще и пользователи, а не только разработчики.
Запрос на объединение веток будет появляться на сайте GitLab каждый раз, когда вы будете вносить изменения в код одной или нескольких веток.
Выглядит это следующим образом:
На сайте появляется большая синяя кнопка Create merge request. Кликаем по ней. 
Затем рассказываем о своем запросе (поясняем, для чего он делается).
Указываем автор запроса в поле Assignee.
Указываем человека, который будет проверять запрос в поле Reviewer.
Потом указываем Milestone (если используете их).
И нажимаем на Create merge request.
Если с запросом все ок, то проверяющий нажмет на кнопку Merge, и весь код перекочует в основную ветку проекта (ну или ту, которую указал автор запроса).
Как добавлять пользователей в проект
К разработке своего приложения/сайта всегда можно привлечь людей со стороны:
Для этого кликаем по кнопке Project information в боковой панели GitLab.
Выбираем пункт Members.
В графу GitLab member or Email address вписываем ник GitLab-пользователя или его email-адрес.
Выбираем для него роль (гость, наблюдатель, разработчик).
Также указываем время действия приглашения (в указанный день приглашенный будет исключен из проекта).
А потом кликаем на Invite. 
Если выбранный человек согласится присоединиться, то ваша команда расширится.
Как создавать баг-репорты
В git-системах есть инструменты, помогающие оповещать разработчиков об ошибках и обсуждать их как с пользователями, так и с коллегами.
Речь идет о разделе Issues. Если возникла проблема, то нужно сообщить о ней тут. Для этого:
Открываем раздел Issues в боковой панели управления.
Затем нажимаем на кнопку New issue. 
Даем имя обнаруженной проблеме, а затем подробно описываем ее в разделе Description.
Затем назначаем ответственного в пункте Assignee и срок, в течение которого нужно найти решение найденной проблемы.
А потом нажимаем на кнопку Create issue. 
Как удалить проект
Открываем настройки проекта и переходим во вкладку General.
Листаем ее до пункта Advanced и справа от него ищем кнопку Expand, которая откроет доступ к дополнительным параметрам.
Вновь пролистываем появившееся меню до упора вниз, пока не наткнемся на кнопку Delete project.
Нажимаем на нее и вписываем название проекта, чтобы его удалить.
Вместо заключения
На этом все. Я рассмотрел базовые возможности GitLab и намеренно не затрагивал аналитические инструменты, интеграцию с Kubernetes и дополнительные функции, пытаясь сконцентрироваться на важнейших концептах GitLab и git. Это то, что вам необходимо для старта, независимо от того, пользовались вы ранее другими системами управлениями репозиториями или нет.