Gitlab как пользоваться: Как пользоваться GitLab | Losst

Содержание

Как пользоваться GitLab | Losst

GitLab — это онлайн сервис для работы с git репозиториями, у которого есть Open Source версия, которую можно установить и развернуть на своем сервере. Разработчики позиционируют свой сервис как альтернативу GitHub и с этой задачей он полностью справляется. Здесь есть все то же самое, что и на GitHub, плюс бесплатные неограниченные частные репозитории, создание команд, редактирование кода прямо в браузере и многое другое.

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

Содержание статьи:

Как пользоваться GitLab

1. Создание аккаунта

Зарегистрироваться на GitLab очень просто. Откройте главную страницу GitLab найдите в правой части экрана форму входа и перейдите на вкладку Register.

Здесь вам нужно ввести ваше имя, логин, адрес электронной почты, согласится с условиями использования и нажать кнопку Register:

После этого вам на почту придет сообщение со ссылкой для подтверждения аккаунта, перейдите по ней:

Теперь ваш аккаунт подтвержден и вы можете в нём авторизоваться:

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

2. Создание репозитория

Чтобы добавить проект GitLab кликните по значку + по центру верхней панели и выберите New Project:

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

Private — доступен только вам;
Internal — доступен всем зарегистрированным пользователям;
Public — доступен абсолютно всем.

Ещё вы можете установить галочку напротив Инициализировать репозиторий файлом README, но если вы хотите залить сюда файлы из уже существующего репозитория, делать этого не следует:

После нажатия на кнопку Create repo вы попадаете на страницу репозитория. Здесь GitLab уже предлагает первоначальный набор действий, чтобы проиниализировать ваш репозиторий. Например, вы можете создать здесь файлы или загрузить сюда файлы из вашего компьютера.

4. Загрузка файлов проекта

Давайте создадим новый локальный репозиторий на компьютере и загрузим его содержимое на GitLab. Для этого создайте папку репозитория, например, test-repo и инициализируйте в ней новый репозиторий командой git:

mkdir test-repo && cd test-repo

git init

Затем давайте создадим файл test.txt:

vi test.txt

This is test losst repo

И зафиксируем изменения:

git add test.txtgit commit -m "Inital commit"

Дальше нам нужно добавить наш удаленный репозиторий с GitLab к нашему локальному.

Для этого выполните:

git remote add origin https://gitlab.com/losst/test-repo.git

Затем отправляем изменения в удаленный репозиторий:

git push origin master

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

Важно отметить, что если удаленный репозиторий не пуст, то у вас не получиться так сделать. Вам нужно будет сначала скачать удаленный репозиторий, слить локальные изменения с ним, а потом уже отправить всё назад.

5. SSH ключи

Во время загрузки данных репозитория на GitLab нам нужно было ввести логин и пароль на сервере. Чтобы этого избежать можно использовать SSH ключи для авторизации. Сначала вам нужно создать такой ключ. Для этого откройте терминал и выполните:

ssh-keygen

Введите путь к файлу, куда нужно сохранить ключ, а пароль оставьте пустым. Будут созданы два файла — открытый ключ с расширением . pub и закрытый. Вам нужен открытый. Откройте его в текстовом редакторе и скопируйте его содержимое в буфер обмена:

vi /home/sergiy/.ssh/id-gitlab

Далее возвращайтесь к интерфейсу GitLab кликните по иконке профиля и выберите

Settings:

Здесь на левой панели найдите пункт SSH Keys. В этом окне найдите поле Key и вставьте туда скопированный ключ. Далее сохраните изменения. Теперь ваш ключ добавлен:

Далее вернитесь в ваш репозиторий, найдите в правом верхнем углу кнопку Clone и кликните по ней. Нас интересует адрес Clone with SSH:

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

git remote remove origin git remote add origin [email protected]:losst/test-repo.git

Настройка ssh GitLab завершена. Теперь все действия будут выполняться по SSH и у вас не будет необходимости вводить логин и пароль.

6. Ветки репозитория

Разберем использование gitlab для работы с ветками. По умолчанию у репозитория есть только одна ветка — это master. Но для реализации дополнительных функций разработку можно выносить в отдельные ветки. В интерфейсе GitLab ветки отображаются слева. Здесь можно выбрать нужную ветку:

Создать новую ветку можно кликнув по значку плюс и выбрав New branch. Но это не обязательно, так как если вы создадите ветку в git и зальете изменения в репозиторий, то ветка появится там автоматически.

Чтобы изменить ветку по умолчанию откройте Settings -> Repository, а потом просто выберите нужную ветку в разделе Default branch:

6. Слияние веток

Поскольку у нас есть ветки и в них разрабатывается функциональность может возникнуть необходимость перенести её из одной ветки в другую. Для этого используются запросы слияния (Merge request gitlab). Давайте добавим ветку new-feature, а в ней создадим файл new-feature с текстом:

git checkout -b new-feature

vi new-feature.txt

New feature with change

git add new-feature.txt
git commit -m "add feature"
git push --set-upstream origin new-feature

Теперь, когда мы перейдем в новую ветку через интерфейс GitLab появится кнопка Create merge request. Нажмите на неё:

Здесь нужно написать описание Merge Request, который вы создаете, выбрать ветку источник и ветку цель. Также можно выбрать пользователя, которому будет оправлено уведомление о созданном запросе:

Далее запрос на слияние нужно одобрить. Вы можете посмотреть изменения нажав кнопку Open IDE или через терминал:

Далее просто нажмите кнопку Merge, если хотите слить ветки. Файлы ветки источника заменят файлы в ветке преемника, поэтому будьте осторожны, чтобы не потерять важные данные.

8. Добавление пользователей

Несмотря на то, что репозитории приватные, возможна работа с gitlab командой. Вы можете добавить к ним неограниченное количество разработчиков. Для этого откройте пункт Settings -> Members. Здесь в поле Select members to invite введите никнеймы или адреса электронной почты пользователей, которых надо пригласить, а в поле Choose a role permission

выберите их уровень доступа:

Затем нажмите кнопку Add to project.

9. Удаление проекта

Чтобы удалить проект с Gitlab надо открыть Settings -> General -> Advanced и выбрать Remove Project в самом низу страницы:

После нажатия на кнопку вам нужно будет ввести имя проекта, после чего он будет удален:

Выводы

В этой статье мы кратко разобрали как пользоваться GitLab для разработки программного обеспечения. Это далеко не все возможности GitLab, которые заслуживают внимания, там ещё есть релизы, сообщения об ошибках, инструменты автоматизации и тестирования, удобный редактор кода и многое другое. В общем это полноценная альтернатива для GitHub если тот сервис больше вам не нравится. А что вы предпочитаете, GitHub или GitLab? Напишите в комментариях!

Что такое GitLab? Настройка и использование GitLab

Мы с вами уже говорили про Git и GitHub. В этой статье расскажем о том, что такое GitLab, как им пользоваться, какая настройка потребуется.

GitLab — это онлайн-сервис, предназначенный для работы с git-репозиториями. Его можно использовать непосредственно на официальном сайте (gitlab.com), зарегистрировав аккаунт, или установить и развернуть на своём сервере.

Возможности GitLab

GitLab — это отличный инструмент для разработчиков, который предоставляет следующие возможности: — управление публичными и приватными git-репозиториями; — управление пользователями и группами, правами доступа к git-репозиториям; — отслеживание ошибок, деплой, анализ кода; — интеграция с разными CI-системами CI (Jenkins и т. п.), организация самостоятельного процесса CI посредством встроенных средств.

Есть и другие возможности (функционал api, wiki страниц, доски задач и идей, отслеживание изменений, комментарии к проектам и прочие). Подробнее можно узнать из официальной документации.

GitLab и GitHub

Как известно, главный конкурент GitLab — это сервис GitHub. Появился он на три года раньше (в 2008), поэтому более популярен. Да что там говорить, GitHub сегодня — это сайт номер один по размещению open source-проектов. Они почти все на нём и размещаются.))) И у многих людей Git напрямую ассоциируется с сервисом GitHub.

Да, плюсов у GitHub много, но мы не будем сейчас сравнивать оба сервиса. Скажем только, что несмотря на повышенную популярность и огромнейшее комьюнити GitHub (26 млн. человек), наблюдается тенденция перехода крупных команд разработчиков на GitLab. Это происходит благодаря расширенным возможностям второго.

Как использовать GitLab? Настройка сервиса

1.

Создание аккаунта

Для начала, зарегистрируемся на сайте GitLab. Для этого нужно перейти на вкладку Register, которая находится в правой части экрана. Появится форма, где нужно будет ввести имя, логин, электронную почту.

Далее вы получите на почту сообщение, где будет находиться ссылка для подтверждения аккаунта. После перехода по ней появится форма авторизации.

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

2. Создание репозитория

Для добавления проекта GitLab потребуется кликнуть по значку +, который находится в центре верхней панели. Далее нужно выбрать New Project:

Теперь вводим имя и описание репозитория, выбираем уровень доступа. Их существует три: — Private. Доступен только для вас; — Internal. К репозиторию смогут получить доступ все зарегистрированные пользователи; — Public. Свободный доступ для всех.

Также можно инициализировать репозиторий файлом README, поставив соответствующую галочку. Однако, если планируете залить файлы из уже существующего Git-репозитория, то не стоит этого делать.

Чтобы попасть на страницу репозитория, нажмите кнопку «Create repo». GitLab предложит первоначальный набор действий с целью проинициализировать ваш репозиторий. В итоге вы сможете создать файлы здесь либо загрузить их из своего ПК.

3. Загрузка файлов проекта

Теперь перейдём к созданию нового локального репозитория на ПК и загрузим содержимое на GitLab. Сначала создадим папку репозитория, назвав её, к примеру, test-repo. Теперь проинициализириуем в ней новый репозиторий, используя команду git:

mkdir test-repo && cd test-repo
git init

Теперь создаём файл test.txt:

vi test.txt
This is test losst repo

И фиксируем изменения:

git add test.txt
git commit -m "Inital commit"

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

git remote add origin https://gitlab. com/losst/test-repo.git

Потом отправим изменения в удалённый репозиторий:

Чтобы отправить данные, введём пароль и логин на GitLab. После обновления страницы на GitLab, увидим наш файл:

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

4. SSH-ключи

При загрузке данных на GitLab требовалось ввести пароль и логин на сервере. Но есть и другой путь — SSH-ключи для авторизации. Для создания ключа выполните:

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

vi /home/sergiy/.ssh/id-gitlab

Потом возвращаемся GitLab-интерфейсу, кликаем по иконке профиля и выбираем настройки Settings:

Потом ищем на левой панели пункт SSH Keys. Далее находим Key и вставляем в соответствующее поле скопированный ключ. Всё, осталось лишь сохранить изменения.

Теперь возвращаемся в репозиторий, находим кнопку Clone (правый верхний угол) и кликаем по ней. Интересует адрес Clone with SSH:

Возвращаемся в локальный репозиторий, удаляем https, добавляем ssh:

На этом настройка ssh в GitLab закончена. С этого момента все действия выполняются по SSH, поэтому вводить логин и пароль не потребуется.

5. Ветки репозитория

Давайте посмотрим, как использовать GitLab при работе с ветками. По умолчанию репозиторий имеет лишь master-ветку. Однако разработку можно выносить и в отдельные ветки, что позволит реализовать дополнительные функции.

Ветки в GitLab-интерфейсе отображаются слева:

Для создания новой, кликаем по значку + и выбираем New branch. Также, если вы создадите ветку в git, а потом зальёте в репозиторий изменения, ветка появится там автоматически.

Если ветку по умолчанию нужно изменить, открываем настройки репозитория (Settings -> Repository), где выбираем нужную ветку в разделе Default branch:

5. Слияние веток

Иногда возникает необходимость выполнить слияние веток. Для этого используют Merge request gitlab — запросы слияния. Продемонстрируем это на ветке new-feature, где создадим файл new-feature с текстом:

git checkout -b new-feature
vi new-feature.txt
New feature with change
git add new-feature.txt
git commit -m "add feature"
git push --set-upstream origin new-feature

Если мы после этого перейдём в новую ветвь с помощью интерфейса GitLab, мы увидим появившуюся кнопку Create merge request. Естественно, нажимаем:

Тут пишем описание Merge Request, выбираем ветку-цель и ветку-источник. Кроме того, можно выбрать пользователя, который получит уведомление о созданном запросе.

Теперь запрос на слияние следует одобрить. Посмотреть изменения можно через терминал или, нажав кнопку Open IDE. Чтобы слить ветки, осталось нажать кнопку Merge.

7. Добавление пользователей

В GitLab можно работать с командой, добавляя неограниченное число разработчиков.

Настройка проста: — открываем Settings ->Members; — в поле Select members to invite вводим никнеймы либо адреса электронной почты тех, кого приглашаем; — в поле Choose a role permission выбираем уровень их доступа; — нажимаем Add to project.

8. Удаление проекта

Настройки для удаления проекта с Gitlab: — открываем Settings -> General -> Advanced; — выбираем и нажимаем Remove Project внизу страницы; — вводим имя проекта, который нужно удалить.

Послесловие

В нашей статье мы вкратце разобрали, как пользоваться GitLab при разработке софта. Однако это далеко не все возможности, которые предоставляет данный сервис. И совершенно неслучайно GitLab сегодня называют полноценной альтернативой GitHub. Впрочем, что выбирать, GitHub или GitLab, — решать вам.

При подготовке статьи использовались материалы из следующих источников: https://losst. ru/kak-polzovatsya-gitlab; https://serveradmin.ru/ustanovka-i-nastroyka-gitlab/?pdf=7240.

Как пользоваться GitLab | Prog-Life

Вы узнаете для чего нужен Gitlab, почему его используют в команде, а также познакомитесь с его основными возможностями.

Как пользоваться GitLab

GitLab — это сервис, предоставляющий возможность работать с репозиториями. С помощью него можно загружать созданный код, совместно работать над его изменением/улучшением. Кроме возможности работать над одним проектом вместе gitlab осуществляет контроль версий. Контроль версий позволяет работать над проектом, исправляя ошибки или повышая эффективность, не затрагивая само ПО, т.е. не подвергая риску его работу. Хранении предыдущих версий позволяет «откатиться» до предыдущей в любой момент или наоборот объединить изменения с действующим программным обеспечением после того, как они будут рассмотрены и утверждены.

Как работает GitLab
Самые важные функции:
1. создание отдельных веток от главной или так называемого «мастера», можно сказать, продакшн-версии проекта. Такое ветвление как бы создает копию, что позволяет эксперементировать, работая над разными участками кода, не затрагивая при этом исходный проект (откуда была создана ветка).
2. Когда вы довольны внесенными изменениями, можно отправить запрос на слияние. Запрос на слияние отправляется владельцу проекта, который может просмотреть внесенные вами изменения и задать любые дополнительные вопросы. Если владельца проекта все устраивает, он может объединить ваши изменения с исходным кодом.
3. подтягивание изменений с удаленного репозитория. Если код проекта обновился, все участники проекта смогут «подтянуть» изменения, то есть обновить проект до самой актуальной верии одной командой,

Работа с GitLab

1. СОЗДАНИЕ АККАУНТА

Для входа в свою учетную запись перейдите по ссылке ссылке.

Если у вас еще нет аккаунта на gitlab нажмите «Register now» и заполните нужные поля. Далее нужно будет подтвердить регистрацию с помощью письма, которое будет отправлено вам на электронную почту.

Если не хотите создавать новую учётную запись — можно войти с помощью существующей учетной записи на github или гугл-аккаунта.

После ввода имени пользователя и пароля, вы окажетесь на главной странице вашего GitLab профиля. Когда у вас будут активные проекты (репозитории), они будут отображаться здесь.

2. СОЗДАНИЕ НОВОГО ПРОЕКТА/РЕПОЗИТОРИЯ

Чтобы создать новый проект нажмите «+«, который находится на верхней панели и нажмите «новый проект» («new project»):

Далее нужно дать имя и краткое описание проекту, а также доступ:
— private — проект будет доступен исключительно вам (и тем, кому вы лично предоставите доступ),
— internal — доступ для всех пользователей gitlab,
— public — доступ открыт всем

Если поставить галочку напротив «Initialize repository with README», то проект инициализируется и создается файл README. txt. Делать это здесь не обязательно!

После заполнения полей, подтверждаем действие нажатием «Create repo«, после чего попадаем на страницу репозитория. На этой странице можно создать файлы или подгрузить их со своего компьютера.

3. ПЕРЕНОС ПРОЕКТА НА УДАЛЕННЫЙ РЕПОЗИТОРИЙ GITLAB

Давайте создадим новый репозиторий на своем компьютере и перенесем его содержимое на GitLab. Так проект станет доступным для всех, кто является участником проекта.
Прежде всего репозиторий нужно создать и инициализировать командой «git»:

Создаем репозиторий с помощью командной строки (название репозитория пусть будет repo_name):


mkdir repo_name

Переходим в репозиторий проекта:


cd repo_name

Инициализируем его:


git init

Давайте создадим файл test_file.txt:


vi test.txt
Это тестовый файл

Теперь зафиксируем изменения(-m означает сообщение комита):


git add test. txt
git commit -m "First commit"

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


git remote add origin https://gl.rncb.ru/project_name/repo_name.git

Чтобы проталкивания изменений в удаленный репозиторий нужно выполнить команду:


git push origin master

После этого потребуется ввести данные учетной записи.
Проект перенесен на удаленный репозиторий. Вы можете зайти на gitlab и проверить.

Если удаленный репозиторий не пуст, например, при создании проекта вы уже инициализировали его, добавив файл README, то выполнить эти действия не получится.

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

4. ДОСТУП ПО SSH-КЛЮЧУ

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

SSH-ключ создаётся с помощью команды:


ssh-keygen

Выберете путь для сохранения там ключа, пароль оставляем пустым. После выполнения команды по указанному сохраняться два файла — открытый ключ (расширение .pub) и закрытый.
Откройте файл с открытым ключом с помощью любого текстового редактора (например, «блокнот«) и скопируйте его содержимое.
Теперь перейдите в интерфейс GitLab -> настройки профиля (settings) -> раздел SSH Keys -> поле Key. В это поле необходимо вставить скопированный ключ и сохранить.

Склонировать репозиторий по ssh-ключу

Далее перейдите в ваш удаленный репозиторий на gitlab, найдите кнопку Clone в правом верхнем углу. Нажав по ней, вы увидите, что проект можно склонировать на локальный компьютер, используя ssh-ключ:

Переходим к локальному репозиторию (на вашем компьютере), удаляем https-адрес и добавляем скопированный ssh адрес:


git remote remove origin
git remote add origin git@gitlab. com:project_name/repo_name.git

Готово! Теперь есть доступ к проекту на gitlab по ssh-ключу. Логин и пароль вводить не надо.

5. РАБОТА С ВЕТКАМИ

По умолчанию у вновь созданного репозитория есть только master ветка. Как уже упоминалось, это главная ветка, там может хранится ПО, которое используется в продакшн.
Для того, чтобы экспериментировать, создавать новые функции, не рискуя при этом вызвать фатальные ошибки или сбой в работе ПО, нужно рабоать в отделных ветках. Например, в отдельную ветку может выноситься новый функционал или в отдельной ветке может работать определенный участник проекта. Вот так в интерфейсе gitlab выглядят ветки:

Создание ветки

Создать новую ветку можно двумя способами:
1. используя git:


git checkout -b new_branch_name

2. используя интерфейс gitlab:

Кликаем по значку «+» и нажимаем «New branch«.

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

Проталкивание локальных изменений в удаленный репозиторий
Итак, представим, что мы сделали какие-то изменения в ветке «new-feature» (в данном случае добавили файл new_file).
Для того, чтобы эти изменения перенеслись в вашу ветку «new-feature» на удаленном репозитории нужно выполнить команды:


git add new_file.txt

git commit -m "add feature"

git push --set-upstream origin new-feature

6. СЛИЯНИЕ ВЕТОК

Для того, чтобы перенести функционал, разработанный в какой-то ветке в другую ветку, нужно делать запрос на слияние (merge request).

Сделать это можно через интерфейс GitLab. Нужно нажать на кнопку «Create merge request«.

Представим, что нужно добавить изменения, сделанные в ветке new-feature к основному проекту, который находится в ветке dev. В качестве source branch выбираем ветку new-feature, а в качестве target branch — целевую ветку, к которой мы хотим добавить изменения (в данном случае dev).

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

Если изменения проверены и вы готовы влить их в целевую ветку, нажмите кнопку «merge». Все изменения будут добавлены в целевую ветку.

! все удаленные в сливаемой ветке файлы удалятся и в целевой ветке при слиянии, а измененные файлы заменят старые. Те файлы, которые вы не меняли останутся в прежнем состоянии.

7. ДОБАВЛЕНИЕ ПОЛЬЗОВАТЕЛЕЙ К ПРОЕКТУ

Как уже упоминалось, зачастую в репозитории работает не один человек, а целая команда. Для того, чтобы добавить к проекту разработчиков откройте настройки (Settings). Перейдите во вкладку Members. Здесь в окне Select или Invite member введите логин или email пользователей, которых хотите пригласить и выберете их роль в проекте выберите. Нажмите кнопу «Invite«.

Сохраняйте статью к себе на стену, чтобы не потерять ⬇

Что такое GitLab, как и для чего он используется

GitLab — это инструмент для хранения и управления репозиториями Git. Он дает возможность выполнять совместную разработку силами нескольких команд, применять обновления кода и откатывать изменения, если это необходимо.

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

В этой статье мы рассмотрим установку бесплатной версии GitLab Community Edition (GitLab CE) на сервер с Ubuntu 20.04 LTS x86_64, сравним GitLab с GitHub, разберемся с возможностями платных и бесплатных версий GitLab и расскажем как пользоваться GitLab. Но для начала подготовим выделенный сервер для разворачивания демо-стенда.

Чтобы создать сервер, откроем панель управления my.selectel.ru и перейдем в меню Серверы и оборудование, затем нажмем кнопку Заказать сервер.

В нашем примере для GitLab используется выделенный сервер фиксированной конфигурации EL09-SSD с процессором Intel Xeon E-2236, 16 Гб оперативной памяти, двух SSD-дисков по 480 Гб и операционной системой Ubuntu 20.04 LTS 64-bit.

После выбора сервера нажимаем кнопку Оплатить сейчас и ожидаем готовности сервера.

Примерно через 2 минуты физический сервер будет готов, а мы пока расскажем о возможностях Gitlab.

Возможности GitLab

Возможности GitLab делятся на следующие категории:

управление (Manage),
планирование (Plan),
создание (Create),
проверка (Verify),
упаковка (Package),
безопасность (Secure),
релизы (Release),
конфигурирование (Configure),
мониторинг (Monitoring),
защита (Defend).

Мы расскажем про основные в каждой категории.

Управление

Аутентификация и авторизация. Двухфакторная аутентификация, интеграция с пользовательскими каталогами (AD/LDAP), гранулярный доступ к объектам в GitLab, поддержка токенов и SSO.
Аналитика. Аналитика продуктивности разработчиков, трекинг выполнения задач группами пользователей.

Планирование

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

Создание

Управление исходным кодом. График коммитов, запросы на слияния веток разработки, интеграция с Jira.
Веб-консоль для редактирования кода. Веб-представление кода в интерфейсе, редактирование кода, синхронизация файлов с исходным кодом.

Проверка

Поддержка процесса Continuous Integration (CI). Встроенные инструменты CI/CD, интеграция с Github, просмотр пайплайнов разработки, онлайн-визуализация HTML-артефактов.
Проверка качества кода и тестирование. Отчеты по качеству кода, юнит-тестам, нагрузочное тестирование, тесты на доступность и юзабилити.

Упаковка

Управление репозиториями. Поддержка репозиториев C/C++, Maven (Java), NPM, NuGet (.NET), Composer (PHP), PyPi (Python) и других.
Управление контейнерами. Поддержка работы с Docker, управление репозиторием через API и вебхуки, приватных контейнерных репозиториев.

Безопасность

Поддержка SAST и DAST. Работа с Static Application Security Testing и Dynamic Application Security Testing включая возможности отчетности.
Сканирование зависимостей и управление уязвимостями. Gitlab поддерживает автоматизированное выявление зависимостей в коде и позволяет строить отчеты по возможным уязвимостям.

Релизы

Поддержка процесса Continuous Delivery (CD). Возможность запуска CI/CD в различных окружениях (Windows, Mac, Linux), поддержка канареечных релизов, обеспечение безопасности пайплайнов.
Оркестрация релизов. Отслеживание релизов, ассоциация релизов с этапами, управление доступом к защищенным окружениям.

Конфигурирование

Управление Kubernetes. Поддержка работы с несколькими кластерами Kubernetes, разворачивание в кластере Kubernetes, управление переменными в зависимости от окружения.
ChatOps и бессерверные вычисления. Разворачивание и другие операции из чата и поддержка выполнения функций через Knative.

Мониторинг

Метрики. Мониторинг производительности приложений, кластеров kubernetes и самого Gitlab с возможностью отправки уведомлений.
Управление инцидентами и логирование. Автоматическое создание инцидентов в случае превышения порогов и отправка логов во внешние системы.

Защита

Web Application Firewall и безопасность контейнеров. Блокировка атак на веб-интерфейс и отслеживание жизненного цикла контейнеров.
Сетевая безопасность. Поддержка микросегментации контейнеров для изоляции потенциально опасных контейнеров и применение политик безопасности.

Полный список возможностей приведен на сайте GitLab. Там же можно узнать подробнее о каждой.

Как установить и настроить GitLab на Ubuntu

Пока вы узнавали о возможностях GitLab, сервер успешно установлен и готов к работе. Подключаемся по SSH к серверу, переходим в директорию /tmp и загружаем установочный скрипт репозиториев GitLab:

# cd /tmp
# curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh

После загрузки скрипта, он необходимо добавить права на его исполнение:

# chmod 777 script.deb.sh

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

# bash /tmp/script.deb.sh

После установки репозитория, можно запускать менеджер пакетов apt и начинать установку GitLab:

# apt install gitlab-ce

После выполнения установки, появится сообщение о готовности GitLab к работе:

Для доступа к GitLab через веб-интерфейс, его необходимо настроить. Для этого откроем для редактирования конфигурации в файле /etc/gitlab/gitlab.rb и укажем переменной external_url в качестве значения URL-адрес сервера.

# vi /etc/gitlab/gitlab.rb

В нашем демо вместо имени используется IP-адрес.

Теперь, чтобы новая конфигурация вступила в силу, необходимо выполнить реконфигурацию GitLab:

# gitlab-ctl reconfigure

После окончания процесса конфигурации, откроется интерфейс GitLab и запрос на изменения пароля администратора.

После изменения пароля необходимо выполнить вход в GitLab:

GitLab полностью готов к работе и даже имеет тестовый проект.

Однако, GitLab по умолчанию работает по протоколу http. Чтобы переключить его на протокол https, необходимо изменить значения переменных letsencrypt[‘enable’], letsencrypt[‘contact_emails’] и в переменной external_url указать протокол https:

letsencrypt['enable'] = true
external_url "https://<внешний IP-адрес>"
letsencrypt['contact_emails'] = ['[email protected]']

После внесения изменений в конфигурацию, выполним реконфигурацию GitLab:

# gitlab-ctl reconfigure

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

Если GitLab установлен во внутренней сети и к нему требуется доступ извне, одним из вариантов организации такого доступа может быть настройка проксирования на nginx-сервере (или proxy_pass) с установкой на него ключа Let’s Encrypt. В этом случае в настройках GitLab можно спокойно оставлять доступ по протоколу http.

Иногда, при попытке доступа через веб-интерфейс, GitLab возвращает ошибку 502. Причины могут быть разные, но основные это: нехватка оперативной памяти, остановка службы gitlab-workhorse и изменение прав доступа к файлу /var/opt/gitlab/gitlab-workhorse/socket. В первом случае проблему решит добавление оперативной памяти, во втором перезагрузка сервисов GitLab, а в третьем предоставление сервису nginx доступа к файлу.

Как работать с GitLab

Чтобы упростить работу с репозиториями из командной строки, необходимо добавить собственные ssh-ключи в GitLab. Генерируем пару ssh-ключей:

# ssh-keygen -t rsa -f ~/.ssh/gitlab

Следующий шаг — вывод содержимого публичного ключа и его копирование в буфер обмена:

# cat ~/.ssh/gitlab.pub

В интерфейсе GitLab перейдем в раздел Settings:

Далее в раздел SSH Keys, где нужно вставить скопированный ключ. После этого можно нажать Add key.

Появится следующий экран:

На этом настройка к репозиториям через SSH-ключ завершена и пришло время создать новый проект. Для этого достаточно нажать на + в центральной части экрана и далее на New project.

Проекту нужно присвоить имя, а также выбрать тип проекта:

приватный (Private),
внутренний (Internal),
публичный (Public).

В первом случае проект будет доступен только вам, во втором всем пользователям данной инсталляции GitLab, в третьем случаем всем подряд и без авторизации.

Нажимаем на кнопку Create project:

После создания проекта можно перейти к его настройке. Например, на представлении Members в проект можно пригласить новых пользователей с различными ролями: Guest, Reporter, Developer, Maintainer:

Основы GitLab — это работа с репозиториями. Теперь загрузим в этот проект имеющийся на рабочей станции git-репозиторий. Для начала добавим ссылку на удаленный репозиторий:

# git remote add origin git@<внешний IP-адрес>:root/selectel-test-project.git

Теперь загрузим репозиторий в GitLab:

# git remote add origin git@<внешний IP-адрес>:root/selectel-test-project.git

Теперь через веб-интерфейс GitLab можно просмотреть исходный код локального репозитория:

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

# git clone git@<внешний IP-адрес>:root/selectel-test-project.git

Другой вариант загрузки — через веб-интерфейс. Для этого на странице проекта необходимо нажать кнопку ↓ и выбрать формат загружаемого архива:

Теперь разберемся, как в GitLab работать с ветками репозитория. По умолчанию работа ведется в ветке master и все предыдущие действия мы выполняли именно в ней. Для реализации изменений и их отслеживание, разработчику важно иметь собственную ветку, код из которой в дальнейшем можно будет передать в master-ветку.

Чтобы создать новую ветку, достаточно в выпадающем меню рядом с символом + нажать на пункт меню New branch:

Новую ветку также можно создать в локальном репозитории Git и затем загрузить её в GitLab. В веб-интерфейсе появится соответствующая запись о новой ветке.

Мы создали в проекте новую ветку development. В меню Settings — Repository можно выбрать ветку, используемую по умолчанию. После выбора нужно нажать на кнопку Save changes.

Поскольку разработка чаще всего ведется в нескольких ветках, в определенный момент времени появится необходимость выполнить их слияние. Cлияние веток — основа GitLab. В GitLab для реализации этого процесса предназначены запросы на слияние (Merge requests). Создадим в локальном репозитории новую ветку и назовем ее staging:

# git checkout -b staging

Создадим новый файл в репозитории и запишем туда произвольный текст:

# vi new-staging.txt

Добавим этот файл к репозиторию:

# git add new-staging.txt

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

# git commit -m "add feature"

И, наконец, загрузим новую ветку в GitLab:

# git push --set-upstream origin staging

Теперь можно проверить наличие новой ветки staging в интерфейсе GitLab. Перейдем в раздел Repository — Branches и обнаружим созданную ветку. Если перейти в нее, там будет созданный на предыдущих шагах файл new-staging.txt.

Перейдем в эту ветку и нажмем кнопку Create merge request:

Здесь нужно указать название слияния, его описание и, при необходимости, выбрать опцию уведомления заинтересованных пользователей. В нижней части этого экрана нужно нажать кнопку Submit merge request:

На следующем экране можно опционально нажать Approve, а затем нажать Merge:

Слияние веток репозитория выполнено.

Чем отличаются GitLab и GitHub

На специальной странице GitLab есть целая таблица сравнения в разрезе тех возможностей, о которых мы рассказывали в начале статьи. Ко всему этому можно добавить, что GitHub появился на 3 года раньше GitLab и является неким стандартом хранения репозиториев решений с открытым исходным кодом. А еще GitHub — полностью облачное решение, GitLab же может работать на локальном сервере или в облаке.

Использование того или иного инструмента обычно основано на предпочтениях людей, принимающих соответствующие решения. С каждым годом GitLab догонял по функционалу GitHub и сейчас уже во многом его превосходит.

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

Какие существуют версии и тарифы GitLab

GitLab имеет две версии — Community Edition (CE) и Enterprise Edition (EE). У первой (именно ее мы устанавливали в этой статье) полностью открытый исходный код, а вторая построена на базе первой, но имеет дополнительные функции, код которых, увы, не открыт для всех желающих. Версия EE также бесплатная в базовой комплектации и производитель рекомендует использовать именно её, если планируется дальнейший переход на платные тарифы.

Линейка тарифов представлена на скриншоте ниже. Цена за пользователя зависит от тех функций, которые включены в подписку.

Ключевой особенностью подписок уровня Premium и Ultimate является поддержка производителя в режиме 24/7. По этой ссылке можно получить полное представление о возможностях каждой из подписок.

Заключение

Мы рассмотрели ключевые возможности GitLab. и основные моменты при установке и работе с этим инструментом. Самая полная документация доступна на странице производителя. Продукт активно развивается и его использование оправдано в проектах любой величины.

Как пользоваться Git (на примере Gitlab) — KAZARIN OnLine

kirill@xxx:test$ git status

На ветке master

Ваша ветка обновлена в соответствии с «origin/master».

Неотслеживаемые файлы:

(используйте «git add <файл>…», чтобы добавить в то, что будет включено в коммит)

README.md

ничего не добавлено в коммит, но есть неотслеживаемые файлы (используйте «git add», чтобы отслеживать их)

kirill@xxx:test$ git checkout -b «add_readme»

Переключено на новую ветку «add_readme»

kirill@xxx:test$ git status

На ветке add_readme

Неотслеживаемые файлы:

(используйте «git add <файл>…», чтобы добавить в то, что будет включено в коммит)

README.md

ничего не добавлено в коммит, но есть неотслеживаемые файлы (используйте «git add», чтобы отслеживать их)

kirill@xxx:test$ git add README.md

kirill@xxx:test$ git commit -m «README file was added»

[add_readme a0747f1] README file was added

1 file changed, 30 insertions(+)

create mode 100644 README.md

kirill@xxx:test$ git push

fatal: Текущая ветка add_readme не имеет вышестоящей ветки.

Чтобы отправить текущую ветку и установить внешнюю ветку как вышестоящую для этой ветки, используйте

git push —set-upstream origin add_readme

kirill@xxx:test$ git push —set-upstream origin add_readme

Подсчет объектов: 3, готово.

Delta compression using up to 4 threads.

Сжатие объектов: 100% (3/3), готово.

Запись объектов: 100% (3/3), 1.16 KiB | 1.16 MiB/s, готово.

Total 3 (delta 0), reused 0 (delta 0)

remote:

remote: To create a merge request for add_readme, visit:

remote: http://гит-сервер/OPS/backups/file-backup-scripts/merge_requests/new?merge_request%5Bsource_branch%5D=add_readme

remote:

To гит-сервер:OPS/backups/file-backup-scripts.git

* [new branch] add_readme -> add_readme

Ветка «add_readme» отслеживает внешнюю ветку «add_readme» из «origin».

Gitlab как пользоваться на русском

GitLab – это онлайн сервис для работы с git репозиториями, у которого есть Open Source версия, которую можно установить и развернуть на своем сервере. Разработчики позиционируют свой сервис как альтернативу GitHub и с этой задачей он полностью справляется. Здесь есть все то же самое, что и на GitHub, плюс бесплатные неограниченные частные репозитории, создание команд, редактирование кода прямо в браузере и многое другое.

Как пользоваться GitLab

1. Создание аккаунта

Зарегистрироваться на GitLab очень просто. Откройте главную страницу GitLab найдите в правой части экрана форму входа и перейдите на вкладку Register. Здесь вам нужно ввести ваше имя, логин, адрес электронной почты, согласится с условиями использования и нажать кнопку Register:

После этого вам на почту придет сообщение со ссылкой для подтверждения аккаунта, перейдите по ней:

Теперь ваш аккаунт подтвержден и вы можете в нём авторизоваться:

2. Создание репозитория

Чтобы добавить проект GitLab кликните по значку + по центру верхней панели и выберите New Project:

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

Private – доступен только вам;
Internal – доступен всем зарегистрированным пользователям;
Public – доступен абсолютно всем.

4. Загрузка файлов проекта

mkdir test-repo && cd test-repo

Затем давайте создадим файл test.txt:

This is test losst repo

И зафиксируем изменения:

git add test.txt
git commit -m «Inital commit»

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

git remote add origin https://gitlab.com/losst/test-repo.git

Затем отправляем изменения в удаленный репозиторий:

git push origin master

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

5. SSH ключи

Введите путь к файлу, куда нужно сохранить ключ, а пароль оставьте пустым. Будут созданы два файла – открытый ключ с расширением .pub и закрытый. Вам нужен открытый. Откройте его в текстовом редакторе и скопируйте его содержимое в буфер обмена:

Далее возвращайтесь к интерфейсу GitLab кликните по иконке профиля и выберите Settings:

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

git remote remove origin
git remote add origin [email protected]:losst/test-repo.git

6. Ветки репозитория

Разберем использование gitlab для работы с ветками. По умолчанию у репозитория есть только одна ветка – это master. Но для реализации дополнительных функций разработку можно выносить в отдельные ветки. В интерфейсе GitLab ветки отображаются слева. Здесь можно выбрать нужную ветку:

6. Слияние веток

git checkout -b new-feature

New feature with change

git add new-feature.txt
git commit -m «add feature»
git push –set-upstream origin new-feature

Теперь, когда мы перейдем в новую ветку через интерфейс GitLab появится кнопка Create merge request. Нажмите на неё:

8. Добавление пользователей

Затем нажмите кнопку Add to project.

9. Удаление проекта

Чтобы удалить проект с Gitlab надо открыть Settings -> General -> Advanced и выбрать Remove Project в самом низу страницы:

После нажатия на кнопку вам нужно будет ввести имя проекта, после чего он будет удален:

Выводы

Публикую перевод моей статьи из блога ГитЛаба про то как начать использовать CI. Остальные переводы гитлабовских постов можно найти в блоге компании Softmart.

Представим на секунду, что вы не знаете ничего о концепции непрерывной интеграции (Continuous Integration — CI) и для чего она нужна. Или вы всё это забыли. В любом случае, начнем с основ.

Представьте, что вы работаете над проектом, в котором вся кодовая база состоит из двух текстовых файлов. Более того, очень важно, чтобы при конкатенации этих файлов в результате всегда получалась фраза «Hello world.» Если это условие не выполняется, вся команда лишается месячной зарплаты. Да, все настолько серьезно.

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

Проблема в том, что в команде десять разработчиков, а человеческий фактор еще никто не отменял.

Неделю назад один новичок забыл запустить скрипт перед отправкой кода, в результате чего трое заказчиков получили поломанные сборки. Хотелось бы в дальнейшем избежать подобного, так что вы решаете положить конец этой проблеме раз и навсегда. К счастью, ваш код уже находится на GitLab, а вы помните про встроенную CI-систему. К тому же, на конференции вы слышали, что CI используется для тестирования.

Запуск первого теста в CI

После пары минут, потраченных на поиск и чтение документации, оказывается, что все что нужно сделать — это добавить две строчки кода в файл .gitlab-ci.yml :

Добавляем, коммитим — и ура! Сборка успешна!

Поменяем во втором файле «world» на «Africa» и посмотрим, что получится:

Сборка неудачна, как и ожидалось.

Итак, у нас теперь есть автоматизированные тесты. GitLab CI будет запускать наш тестовый скрипт при каждом пуше нового кода в репозиторий.

Возможность загрузки результатов сборки

Следующим бизнес-требованием является архивация кода перед отправкой заказчикам. Почему бы не автоматизировать и его?

Все, что для этого нужно сделать — определить еще одну задачу для CI. Назовем ее «package»:

В результате появляется вторая вкладка

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

Проверяем… Все на месте:

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

Последовательное выполнение задач

Задача ‘package’ должна выполняться только при успешном прохождении тестов. Определим порядок выполнения задач путем введения стадий ( stages ):

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

Посмотрим на получившиеся артефакты:

Скачивание файла «compile» нам ни к чему, поэтому ограничим длительность жизни временных артефактов 20 минутами:

Итоговая функциональность конфига впечатляет:

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

Какие образы Docker лучше использовать

Прогресс налицо. Однако, несмотря на наши усилия, сборка до сих пор проходит медленно. Взглянем на логи:

Что, простите? Ruby 2.1?

Зачем тут вообще Ruby? А затем, что GitLab.com использует образы Docker для запуска сборок, а по умолчанию для этого используется образ ruby:2.1 . Само собой, в этом образе содержится множество пакетов, которые нам ни к чему. Спросив помощи у гугла, узнаем, что существует образ alpine , который представляет собой практически «голый» образ Linux.

Для того, чтобы использовать этот образ, добавим image: alpine в .gitlab-ci.yml .
Благодаря этому время сборки сокращается почти на три минуты:

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

Работа со сложными сценариями

Теперь представим, что у нас появился новый заказчик, который хочет, чтобы вместо .gz архива наше приложение поставлялось в виде образа .iso . Поскольку весь процесс сборки реализован через CI, все, что нам нужно сделать — добавить еще одну задачу. Образы ISO создаются с помощью команды mkisofs. В итоге конфигурационный файл должен выглядеть следующим образом:

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

А тем временем сборка не удалась:

Проблема в том, что конманда mkisofs не входит в состав образа alpine , так что нужно установить ее отдельно.

Установка дполнительного ПО

На сайте Alpine Linux указано, что mkisofs входит в состав пакетов xorriso и cdrkit . Для установки пакета нужно выполнить следующие команды:

Все это — тоже валидные команды CI. Полный список команд в разделе script должен выглядеть следующим образом:

С другой стороны, семантически более корректно выполнять команды, ответственные за установку пакетов до раздела script , а именно в разделе before_script . При размещении этого раздела в верхнем уровне файла конфигурации, его команды будут выполнены раньше всех задач. Однако в нашем случае достаточно выполнить before_script раньше одной определенной задачи.

Итоговая версия .gitlab-ci.yml :

А ведь мы только что создали конвейер! У нас есть три последовательные стадии, при этом задачи pack-gz и pack-iso стадии package выполняются параллельно:

Подводя итоги

В этой статье приведены далеко не все возможности GitLab CI, однако пока что остановимся на этом. Надеемся вам понравился этот небольшой рассказ. Приведенные в нем примеры были намеренно тривиальными — это было сделано для того, чтобы наглядно показать принципы работы CI не отвлекаясь на незнакомые технологии. Давайте подытожим изученное:

Для того, чтобы передать выполнение определенной работы в GitLab CI, нужно определить одну или более задач в .gitlab-ci.yml .
Задачам должны быть присвоены названия, советуем делать их осмысленными, чтобы потом самим не запутаться.
В каждой задаче содержится набор правил и инструкций для GitLab CI, определяющийся ключевыми словами.
Задачи могут выполняться последовательно, параллельно, либо вы можете задать свой собственный порядок выполнения, создав конвейер.
Существует возможность передавать файлы между заданиями и сохранять их как артефакты сборки для последующего скачивания через интерфейс.

В последнем разделе этой статьи приведен более формализованный список терминов и ключевых слов, использованных в данном примере, а также ссылки на подробные описания функциональности GitLab CI.

Описания ключевых слов и ссылки на документацию

Ключевое слово/термин	Описание
.gitlab-ci.yml	Конфигурационный файл, в котором содержатся все определения сборки проекта
script	Определяет исполняемый shell-скрипт
before_script	Определяет команды, которые выполняются перед всеми заданиями
image	Определяет используемый Docker-образ
stage	Определяет стадию конвейера ( test по умолчанию)
artifacts	Определяет список артефактов сборки
artifacts:expire_in	Используется для удаления загруженных артефактов по истечению определенного промежутка времени
pipeline	Конвейер — набор сборок, которые выполняются стадиями

Также обратите внимание на другие примеры работы с GitLab CI:

Комментарии 17

compile:
stage: compile
script: cat file1.txt file2.txt > compiled.txt
artifacts:
paths:
— compiled.txt

А для чего указывать артефакт в задаче compile? Файл compiled.txt понятно, он нам будет нужен в следующих задачах. А зачем его описывать как артефакт?

artifacts используется и для передачи файлов между stages, и для попадания в downloadable artifacts. Возможно это поменятся, но пока так.

А что значит «для передачи файлов между stages»?

В следующих стадиях/задачах используется имя файла compiled.txt. Я так понимаю, это тот самый файл compiled.txt, который создался в задаче compile. Вот просто создался он в задаче compile и лежит себе, а в следующих задачах мы к нему обращаемся.

Без указания артефакта мы не сможем обратиться в нему в следующей задаче? Он будет удален по окончанию задачи compile? А указание артефакта это типа «поставить галочку, что этот файл удалять не надо»?

Подскажите, можно ли иметь единый .gitlab-ci.yml для всех веток?

На стадии его написания многократно приходится синхронизировать его между ветками.

И еще вопрос, можно как-то динамически формировать имя артефакта?
У меня после сборки получается файл package-$-$.el7.centos.$.rpm при чем переменные вычисляются в процессе сборки.

Функционала меньше, чем в Jenkins (это нормально, нужно учитывать):
— нет постоянных ссылок на скачивание последних артефактов (latest, а не номер билда; удобно для скриптов бутстрапа, например)
— вроде бы в последних версиях ручной запуск появился, но нет параметризированного запуска (может и не нужно, можно тот же список серверов забить в файл отдельными ручными работами, но нужно учитывать при проектировании)
— нет работ не привязанных к ветке/репозитарию (из-за этого придется для некоторых вещей сохранить Jenkins)
— нотификации (типа интеграции со слаком) идут вне файла настройки ci

Текущие минусы:
— долго промучился, но команды сборки докера в докере не заработали (ни docker in docker, который не предназначен для систем CI и постоянно в документации Gitlab CI упоминается; ни пробрасывание сокета докера), использую отдельный shell runner для этого.
— кеширует только после успешного завершения работы (например, пока настраиваешь работу каждый раз качает плагины maven)
— медленно (пофайлово?) сохраняет кеш
— нет способа через UI сбросить кеш и посмотреть какие кеши есть. все-таки кеши время от времени приходится сбрасывать
— по ощущениям собирает медленней Jenkins, относительно долго (секунд 15) запускается любая докер-работа с одной командой echo
— нет готового рецепта для Java/Maven, что-то настроил, но еще не все

В целом, удобно, что интегрировано, но еще сыро.

Можно ли указать в качестве зависимости другой проект, что бы он тоже подтянулся для сборки?
И можно ли шарить артефакты между проектами?

Такой вопрос, стокнулся с казалось бы тривиальной задачей в Jenkins — необходимо запускать job при попадании нового тега (с определенным именем, например build_[0-9] <6,10>). Казалось бы все должно быть очень просто, а на деле оказалось что нет. Например у нас есть следующая история

Так вот в Jenkins cборка будет запущена только для head, для остальных 3х тегов она будет игнорироваться. Можно ли в gitlab ci обеспечить сборку в любом «направлении», чтобы при командах

я получил в итоге 4 билда?

Ничего из описанного не работает:( Вообще не запускается, появляется значок «pending» и всё.

Я так понимаю, нужен некий раннер. Какой минимум нужно сделать, чтобы запустить хотя бы самый простейший тест?

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

Blog about IT, Me, My travels, vacations, etc…

Добрый день! Данная статья представляет собой краткий мануал как пользоваться 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 (но только публичную часть):

(если что, я тут сократил ключ чтобы весь не вставлять)

/ . ssh / test – key . pub

Плюс советую поиграться с настройкой тем и редактора: 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 в котором опишем содержимое проекта:

Git — GitLab

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

Установка

GitLab — это веб-приложение на основе базы данных, так что его установка немного сложней, чем у некоторых других серверов Git. К счастью, этот процесс хорошо документирован и поддерживается. GitLab настоятельно рекомендует установить GitLab на ваш сервер через официальный пакет Omnibus GitLab.

Другие варианты установки:

GitLab Helm chart для использования с Kubernetes.
Официальные образы GitLab для использования с Docker.
Из исходных файлов.
Облачный провайдер, такой как AWS, Google Cloud Platform, Azure, OpenShift или Digital Ocean.

Администрирование

Административный интерфейс GitLab доступен через веб. Просто направьте ваш браузер на имя или IP-адрес хоста, где установлен GitLab, и войдите как администратор. Имя пользователя по умолчанию [email protected], пароль по умолчанию 5iveL!fe (вас попросят изменить их при входе). Войдя, нажмите иконку «Административная зона» в меню справа и сверху.

Рисунок 50. Пункт «Административная зона» в меню GitLab

Пользователи

Пользователи в GitLab — это учётные записи, соответствующие людям. Пользовательские учётные записи не очень сложны; в основном это набор персональной информации, прикреплённый к имени. У каждого пользователя есть пространство имён, логически группирующее проекты данного пользователя. Если у пользователя jane есть проект project, адрес этого проекта будет http://server/jane/project.

Рисунок 51. Экран управления пользователями GitLab

Удаление пользователя может быть выполнено двумя способами. «Блокирование» («Blocking») пользователя запрещает ему вход в GitLab, но все данные в его пространстве имен сохраняются, и коммиты, подписанные этим пользователем, будут указывать на его профиль.

«Разрушение» («Destroying») пользователя, с другой стороны, полностью удаляет его из базы данных и файловой системы. Все проекты и данные в его пространстве имен удаляются, как и все принадлежащие ему группы. Конечно, этим более постоянным и разрушительным действием пользуются реже.

Группы

Группы GitLab — это коллекция проектов с указанием того, как пользователи получают к ним доступ. Каждая группа имеет пространство имён проектов (так же как и пользователи), так что если в группе training есть проект materials, его адрес будет http://server/training/materials.

Рисунок 52. Экран управления группами GitLab

Каждая группа связана с пользователями, каждый из которых имеет уровень доступа к проектам группы и к самой группе. Он разнится от «Гостя» («Guest», только проблемы и чат) до «Владельца» («Owner», полный контроль над группой, её членами и проектами). Типы разрешений слишком обширны, чтобы перечислять их здесь, но на экране управления GitLab есть полезная ссылка с описанием.

Проекты

Проект GitLab примерно соответствует одному git-репозиторию. Каждый проект принадлежит одному пространству имён, групповому или пользовательскому. Если проект принадлежит пользователю, владелец контролирует, кто имеет доступ к проекту; если проект принадлежит группе, действуют групповые уровни доступа для пользователей.

Каждый проект также имеет уровень видимости, который контролирует, кто имеет доступ на чтение страниц проекта или репозитория. Если проект Приватный (Private), владелец должен явно дать доступ на чтение отдельным пользователям. Внутренний (Internal) проект виден любому вошедшему пользователю GitLab, а Публичный (Public) проект видим всем. Это относится как к доступу git fetch, так и к доступу к проекту через веб-интерфейс.

Хуки

GitLab включает поддержку хуков (перехватчиков, hooks) на уровне проектов и всей системы. В обоих случаях, когда происходит некоторое событие, сервер GitLab выполняет запрос HTTP POST с осмысленным JSON-содержанием. Это отличный способ соединить ваши git-репозитории и инсталляцию GitLab с автоматикой инфраструктуры разработки, такой как сервера непрерывной интеграции, комнаты чатов или инструменты деплоя.

Базовое использование

Первое, чего вы захотите от GitLab, это создать новый проект. Это достигается нажатием иконки «+» на панели инструментов. Будут запрошены имя проекта, пространство имён, которому он должен принадлежать, и уровень видимости. Большинство из этих настроек можно потом изменить через интерфейс настроек. Нажмите «Создать проект» («Create Project»), чтобы закончить.

Когда проект создан, вы, наверное, захотите соединить его с локальным git-репозиторием. Каждый проект может быть доступен через HTTPS или SSH, каждый из которых может быть использован для указания удалённого репозитория. Адреса (URL) видимы наверху домашней страницы проекта. Для существующего локального репозитория, следующая команда создаст удалённый репозиторий с именем gitlab и размещением на сервере:

$ git remote add gitlab https://server/namespace/project.git

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

$ git clone https://server/namespace/project.git

Веб-интерфейс даёт доступ к нескольким полезным видам самого репозитория. Домашняя страница каждого проекта показывает недавнюю активность, а ссылки наверху ведут на список файлов проекта и журнала коммитов.

Совместная работа

Самый простой метод совместной работы над проектом GitLab — это выдача другому пользователю прямого доступа на запись (push) в git-репозитории. Вы можете добавить пользователя в проект в разделе «Участники» («Members») настроек проекта, указав уровень доступа (уровни доступа кратко обсуждались в Группы). Получая уровень доступа «Разработчик» («Developer») или выше, пользователь может беспрепятственно отсылать свои коммиты и ветки непосредственно в репозиторий.

Другой, более разобщённый способ совместной работы — использование запросов на слияние (merge requests). Эта возможность позволяет любому пользователю, который видит проект, вносить свой вклад подконтрольным способом. Пользователи с прямым доступом могут просто создать ветку, отослать в неё коммиты и открыть запрос на слияние из их ветки обратно в master или любую другую ветку. Пользователи без доступа на запись могут «форкнуть» репозиторий («fork», создать собственную копию), отправить коммиты в эту копию и открыть запрос на слияние из их форка обратно в основной проект. Эта модель позволяет владельцу полностью контролировать, что попадает в репозиторий и когда, принимая помощь от недоверенных пользователей.

Запросы на слияние и проблемы (issues) это основные единицы долгоживущих дискуссий в GitLab. Каждый запрос на слияние допускает построчное обсуждение предлагаемого изменения (поддерживая облегчённое рецензирование кода), равно как и общее обсуждение. И те и другие могут присваиваться пользователям или организовываться в вехи (milestones).

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

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

Git — это распределенная система контроля версий с открытым исходным кодом. GitLab построен поверх Git.

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

Для быстрого ознакомления с командами Git загрузите шпаргалку Git.

Подробнее о преимуществах работы с Git и GitLab:

Чтобы визуализировать, что вы делаете локально, вы можете установить Приложение Git с графическим интерфейсом.

Терминология Git

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

Репозиторий

В GitLab файлы хранятся в репозитории . Репозиторий похож на то, как вы хранить файлы в папке или каталоге на вашем компьютере.

Удаленный репозиторий относится к файлам в GitLab.
Локальная копия относится к файлам на вашем компьютере.

Часто слово «репозиторий» сокращается до «репо».

В GitLab репозиторий содержится в проекте .

Вилка

Если вы хотите внести свой вклад в чей-то репозиторий, вы делаете его копию. Эта копия называется вилкой . Этот процесс называется «создание вилки».

При форке репо вы создаете копию проекта в собственном пространство имен. Затем у вас есть права на запись для изменения файлов проекта. и настройки.

Например, вы можете включить этот проект https://gitlab.com/gitlab-tests/sample-project/ в свое пространство имен. Теперь у вас есть собственная копия репозитория. Вы можете просмотреть пространство имен в URL-адресе, например https://gitlab.com/your-namespace/sample-project/ . Затем вы можете клонировать репозиторий на свой локальный компьютер, работать с файлами и отправлять изменения обратно в исходный репозиторий.

Разница между загрузкой и клонированием

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

Клонирование репозитория аналогично загрузке, за исключением того, что при этом сохраняется соединение Git. с удаленным репозиторием. Затем вы можете изменить файлы локально и загрузить изменения в удаленный репозиторий на GitLab.

Тяни и толкай

После сохранения локальной копии репозитория и изменения файлов на вашем компьютере вы можете загрузить изменения в GitLab. Это называется , нажимая на удаленный, потому что вы используете команду git push .

При изменении удаленного репозитория ваша локальная копия остается позади. Вы можете обновить свою локальную копию новым изменения в удаленном репозитории. Это называется , извлекающим с пульта дистанционного управления, потому что вы используете команду git pull .

Предварительные требования

Чтобы начать использовать GitLab с Git, выполните следующие задачи:

Открыть терминал

Чтобы выполнять команды Git на вашем компьютере, вы должны открыть терминал (также известный как command приглашение, командная оболочка и командная строка).Вот несколько вариантов:

Для пользователей macOS:
- Встроенный терминал. Нажмите ⌘ команду + пробел и введите терминал .
- iTerm2. Вы можете интегрировать его с zsh и oh my zsh для выделения цвета и других дополнительных функций.
Для пользователей Windows:
- Встроенная командная строка. На панели задач Windows выберите значок поиска и введите cmd .
- PowerShell.
- Git Bash.Он встроен в Git для Windows.
Для пользователей Linux:

Установить Git

Определите, установлен ли Git на вашем компьютере, открыв терминал и запустив эту команду:

Если установлен Git, вывод будет:

Если ваш компьютер не распознает git как команду, необходимо установить Git. После установки Git запустите git --version , чтобы убедиться, что он установлен правильно.

Настроить Git

Чтобы начать использовать Git со своего компьютера, вы должны ввести свои учетные данные идентифицировать себя как автора своей работы.Имя пользователя и адрес электронной почты должны соответствовать тем, которые вы используете в GitLab.

В вашей оболочке добавьте свое имя пользователя:
```
  git config --global user.name "your_username"
  
```
Добавьте свой адрес электронной почты:
```
  git config --global user.email "[email protected]"
  
```
Чтобы проверить конфигурацию, запустите:
```
  git config --global --list
  
```
Параметр --global указывает Git всегда использовать эту информацию для всего, что вы делаете в своей системе.Если опустить --global или использовать --local , конфигурация применяется только к текущему репозиторий.

Подробнее о том, как Git управляет конфигурациями, можно узнать в Документация по настройке Git.

Выберите репозиторий

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

Чтобы использовать репозиторий в примерах на этой странице:

Перейдите на https: // gitlab.com / gitlab-tests / sample-project /.
В правом верхнем углу выберите Вилка .
Выберите пространство имен для вашей вилки.

Проект станет доступен по адресу https://gitlab.com//sample-project/ .

Вы можете форкнуть любой проект, к которому у вас есть доступ.

Клонировать репозиторий

Когда вы клонируете репозиторий, файлы из удаленного репозитория загружаются на ваш компьютер, и соединение создается.

Для этого подключения необходимо добавить учетные данные. Вы можете использовать SSH или HTTPS. SSH рекомендуется.

Клон с SSH

Клонируйте с SSH, если вы хотите пройти аутентификацию только один раз.

Выполните аутентификацию с помощью GitLab, следуя инструкциям в документации по SSH.
Перейдите на целевую страницу своего проекта и выберите Клон . Скопируйте URL-адрес Clone с SSH .
Откройте терминал и перейдите в каталог, в который вы хотите клонировать файлы.Git автоматически создает папку с именем репозитория и загружает туда файлы.

Выполните эту команду:

  git clone [email protected]: gitlab-tests / sample-project.git

Для просмотра файлов перейдите в новый каталог:

Вы также можете клонировать репозиторий и открывать его прямо в Visual Studio Code.

Клон с HTTPS

Клонировать с HTTPS, если вы хотите аутентифицироваться каждый раз, когда выполняете операцию между вашим компьютером и GitLab.

Перейдите на целевую страницу своего проекта и выберите Клон . Скопируйте URL-адрес для Clone с HTTPS .
Откройте терминал и перейдите в каталог, в который вы хотите клонировать файлы.
Выполните следующую команду. Git автоматически создает папку с именем репозитория и загружает туда файлы.
```
  git clone https://gitlab.com/gitlab-tests/sample-project.git
  
```
GitLab запрашивает ваше имя пользователя и пароль:
- Если для вашей учетной записи включена двухфакторная аутентификация, необходимо использовать токен личного доступа. с разрешениями read_repository или write_repository вместо пароля вашей учетной записи.
- Если у вас не включена двухфакторная аутентификация, используйте пароль своего аккаунта.
Для просмотра файлов перейдите в новый каталог:

Примечание В Windows, если вы несколько раз ввели неправильный пароль и появится сообщение Доступ запрещен , добавьте свое пространство имен (имя пользователя или группу) в путь: git clone https: //[email protected]/gitlab-org/gitlab.git .

Преобразование локального каталога в репозиторий

Вы можете инициализировать локальную папку, чтобы Git отслеживал ее как репозиторий.

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

Добавить пульт

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

Чтобы добавить пульт к вашей локальной копии:

В GitLab создайте проект для хранения ваших файлов.
Посетите домашнюю страницу этого проекта, прокрутите вниз до Нажмите существующую папку и скопируйте команду, которая начинается с git remote add .
На вашем компьютере откройте терминал в инициализированном каталоге, вставьте скопированную команду и нажмите введите :
```
  git удаленное добавление источника git @ gitlab.com: имя пользователя / projectpath.git
  
```

После этого вы можете подготовить свои файлы и загрузить их в GitLab.

Просмотр удаленных репозиториев

Для просмотра удаленных репозиториев введите:

Флаг -v означает подробный.

Скачать последние изменения в проекте

Чтобы работать над последней копией проекта, вы потянете , чтобы получить все изменения, внесенные пользователями. с момента последнего клонирования или удаления проекта.Заменить <имя-филиала> . с именем вашей ветки по умолчанию чтобы получить основной код ветки, или замените его именем ветки ветки вы в настоящее время работаете.

  git pull <УДАЛЕННЫЙ> <имя-ветки>

Когда вы клонируете репозиторий, REMOTE обычно origin . Вот где репозиторий был клонирован, и он указывает SSH или HTTPS URL репозитория на удаленном сервере. <имя-филиала> — обычно имя вашего ветка по умолчанию, но это может быть любая существующий филиал.При необходимости вы можете создать дополнительные именованные пульты дистанционного управления и ответвления.

Подробнее о том, как Git управляет удаленными репозиториями, можно узнать в Документация Git Remote.

Филиалов

Ветвь — это копия файлов в репозитории на момент создания ветки. Вы можете работать в своей ветке, не затрагивая другие ветки. Когда вы готовы внести изменения в основную базу кода, вы можете объединить свою ветку в ветка по умолчанию, например main .

Используйте ветки, когда вы:

Хотите добавить код в проект, но не уверены, работает ли он должным образом.
Сотрудничаем над проектом с другими и не хотим, чтобы ваша работа смешивалась.

Новую ветвь часто называют функциональной ветвью , чтобы отличать ее от ветка по умолчанию.

Создать филиал

Чтобы создать ветку функции:

  git checkout -b <имя-ветки>

Имена веток не могут содержать пустые пробелы и специальные символы.Используйте только строчные буквы, цифры, дефисы ( - ) и подчеркивания ( _ ).

Перейти в филиал

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

Чтобы переключиться на существующий филиал:

  git checkout <имя-ветки>

Например, чтобы перейти на основную ветку :

Посмотреть различия

Чтобы просмотреть различия между локальными неустановленными изменениями и последней версией что вы клонировали или вытащили:

Просмотреть файлы, в которых есть изменения

Когда вы добавляете, изменяете или удаляете файлы или папки, Git знает об изменениях.Чтобы проверить, какие файлы были изменены:

Добавить и зафиксировать локальные изменения

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

Чтобы подготовить файл для фиксации:
```
  git add <имя-файла ИЛИ имя-папки>
  
```
Повторите шаг 1 для каждого файла или папки, которые вы хотите добавить. Или, чтобы разместить все файлы в текущем каталоге и подкаталоге, введите git add..
Подтвердите, что файлы были добавлены в постановку:
Файлы должны отображаться зеленым цветом.

Чтобы зафиксировать подготовленные файлы:

  git commit -m «КОММЕНТАРИЙ ДЛЯ ОПИСАНИЯ НАЗНАЧЕНИЯ ЗАВЕРШЕНИЯ»

Сценарий и фиксация всех изменений

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

  git commit -a -m «КОММЕНТАРИЙ ДЛЯ ОПИСАНИЯ НАЗНАЧЕНИЯ КОММИТАЦИИ»

Отправить изменения в GitLab.ком

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

  git push <удаленный> <имя-ветки>

Например, чтобы отправить ваши локальные коммиты в основную ветку удаленного источника origin :

Иногда Git не позволяет вам отправить в репозиторий. Вместо, вы должны принудительно обновить.

Удалить все изменения в ветке

Чтобы отменить все изменения в отслеживаемых файлах:

Это действие удаляет изменений файлов, а не сами файлы.Не отслеживаемые (новые) файлы не меняются.

Отменить все изменения, которые были добавлены в область подготовки.

Чтобы отключить (удалить) все файлы, которые не были зафиксированы:

Отменить последнюю фиксацию

Чтобы отменить самую последнюю фиксацию:

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

Внимание! Коммит Git не следует отменять, если вы его уже отправили. в удаленный репозиторий. Хотя вы можете отменить фиксацию, лучший вариант — избегать ситуацию в целом, работая аккуратно.

Вы можете узнать больше о различных способах отмены изменений в Git. Документация Git Undoing Things.

Объединить ветку с веткой по умолчанию

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

  git checkout <ветка-функция>
git merge <ветка по умолчанию>

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

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

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

Для ознакомления с более продвинутыми методами Git см. Git rebase, force-push и конфликты слияния.

Синхронизировать изменения в разветвленном репозитории с восходящим потоком

Чтобы создать копию репозитория в вашем пространстве имен, вы его разветвляете. Изменения, внесенные в вашу копию репозитория, не синхронизируются автоматически с оригиналом.Чтобы синхронизировать проект с исходным проектом, вам нужно извлечь из исходного репозитория.

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

Теперь вы можете использовать восходящего потока как <удаленный> с по извлекать новых обновлений из исходного репозитория и используйте исходный код для проталкивания локальных изменений и создания запросов на слияние.

Редактировать файлы через командную строку

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

Начать работу над своим проектом

Чтобы работать над проектом Git локально (со своего компьютера), с помощью командной строки, сначала вам нужно клонировать (скопировать) его в твой компьютер.

Работа с файлами в командной строке

В этом разделе приведены примеры некоторых основных команд оболочки, которые могут оказаться полезными.Для получения дополнительной информации поищите в Интернете команду bash .

Кроме того, вы можете редактировать файлы с помощью редактора по вашему выбору (IDE) или пользователя GitLab. интерфейс (не локально).

Общие команды

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

Команда	Описание
`cd НАИМЕНОВАНИЕ КАТАЛОГА`	Зайдите в каталог, чтобы работать с ним
`кд..`	Вернуться на один каталог
`лс`	Показать, что находится в текущем каталоге
`лс а *`	Список содержимого текущего каталога, начинающегося с `a`
`ls * .md`	Список содержимого текущего каталога, заканчивающегося на `.md`
`mkdir НАЗВАНИЕ ВАШЕГО КАТАЛОГА`	Создать новый каталог
`cat README.мкр`	Показать содержимое ранее созданного текстового файла
`pwd`	Показать текущий каталог
`прозрачный`	Очистить окно оболочки

Создать текстовый файл в текущем каталоге

Чтобы создать текстовый файл из командной строки, например README.md , выполните следующие действия. шаги:

  сенсорный README.md
нано README.md
#### ДОБАВИТЬ ИНФОРМАЦИЮ
#### Нажмите: control + X
#### Тип: Y
#### Нажмите Ввод

Удалить файл или каталог

Удалить (удалить) файл или каталог легко, но будьте осторожны:

Внимание: навсегда удалит файл.

Внимание: навсегда удалит каталог, а — все его содержимого.

Просмотр и выполнение команд из истории

Вы можете просмотреть историю всех команд, которые вы выполнили из командной строки, а затем при необходимости выполните любой из них еще раз.

Сначала перечислите команды, которые вы выполнили ранее:

Затем выберите команду из списка и проверьте номер рядом с командой ( 123 , Например) .Выполните ту же полную команду с помощью:

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

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

Внимание! Будьте осторожны с командами, которые вы запускаете с sudo .Некоторые команды могут вызывать повреждение ваших данных или системы.

Пример последовательности задач Git

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

Что такое GitLab и как им пользоваться?

GitLab была четвертой по темпам роста частной компанией-разработчиком программного обеспечения в Америке в 2018 году. Компания предоставляет центральный сервер, который управляет репозиториями Git и используется для упрощения административных задач многих корпораций по всему миру.Согласно Википедии, GitLab имеет более 100 000 пользователей и используется крупными, известными организациями, такими как IBM, Sony, Goldman Sachs и NASA.

Это руководство по GitLab включает следующие темы:

Что такое Git?
Что такое GitLab?
История Gitlab
Зачем нужен GitLab?
Demo — первый проект в GitLab
Особенности Gitlab
Преимущества Gitlab
Недостатки Gitlab

Прежде чем мы углубимся в детали GitLab, давайте сначала разберемся с его актуальностью, рассмотрев вариант использования — Goldman Sachs.

Goldman Sachs Group, Inc. — многонациональный инвестиционный банк и компания, предоставляющая финансовые услуги, предоставляющая услуги в области управления инвестициями, ценными бумагами, активами, первичным маклерством и андеррайтингом ценных бумаг. Организация имеет офисы во многих крупных финансовых центрах по всему миру и насчитывает более 38 000 сотрудников.

Даже такие крупные организации, как Goldman Sachs, сталкиваются со своими уникальными проблемами и препятствиями. Вот некоторые из наиболее серьезных проблем, с которыми столкнулась Goldman Sachs:

Магистерская программа для инженеров DevOps

Мост между разработчиками программного обеспечения и операторамиИзучить курс

Вызовы

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

Решение

GitLab спешит на помощь!

GitLab помог командам разработчиков устранить сложность инструментальной цепочки и ускорить внедрение DevOps. Это позволило команде разработать приложение, которое позволило разработчикам Goldman Sachs управлять всеми усилиями с помощью единого пользовательского интерфейса и упростило администрирование за счет использования одного централизованного экземпляра для всех репозиториев.

Теперь, когда вы увидели один пример применимости GitLab, давайте сосредоточимся на его основах. Чтобы лучше понять основы GitLab, мы должны начать с понимания части имени «Git».

Что такое Git?

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

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

Теперь, когда мы ознакомились с основами Git, давайте взглянем на репозиторий хостинга, GitLab.

Что такое GitLab?

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

GitLab помогает командам сократить жизненный цикл продукта и повысить производительность, что, в свою очередь, создает ценность для клиентов. Приложение не требует, чтобы пользователи управляли авторизацией для каждого инструмента. Если разрешения установлены один раз, то каждый в организации будет иметь доступ к каждому компоненту.

Чтобы получить доступ к большему количеству функций, клиенты могут выбрать платную версию GitLab по цене от 4 долларов за пользователя в месяц.

История GitLab

GitLab изначально был полностью бесплатным программным обеспечением с открытым исходным кодом, распространяемым по лицензии MIT. Он был разделен на две отдельные версии — GitLab CE (Community Edition) и GitLab EE (Enterprise Edition) в июле 2013 года. GitLab EE был установлен под ограниченной лицензией, но исходный код оставался общедоступным, тогда как модель лицензирования GitLab CE осталась неизменной. В 2017 году GitLab объявил, что их код станет полностью открытым по лицензии MIT.

Зачем использовать GitLab?

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

Чтобы лучше понять основы GitLab и его функциональность, давайте посмотрим на демонстрацию.

Изучите основы Git VCS и поймите, как настроить Git в вашей системе, с помощью учебного курса Git. Ознакомьтесь с курсом прямо сейчас.

GitLab Tutorial Demo — Создание вашего первого проекта в GitLab

Откройте gitlab.com

Войдите в свою учетную запись.

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

Выберите имя и описание, а также, хотите ли вы, чтобы оно было частным или общедоступным.

Откройте свой Git Bash

В качестве первого шага настройте ваше имя пользователя и адрес электронной почты.

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

Затем создайте первый репозиторий.

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

mkdir учебник

cd учебник

БЕСПЛАТНОЕ обучение GIT

Изучите основы GITEnroll прямо сейчас

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

Перейдя в эту папку, вы обнаружите, что в настоящее время она пуста.

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

Вы заметите, что на экране появляется что-то, называемое «мастером». Каждый раз, когда репозиторий Git создается в первый раз, он создает ветку, которая называется мастером.

Перейдите в папку и найдите скрытую папку «.git».

Если вы проверите папку, вы увидите несколько каталогов и конфигураций.Убедитесь, что вы не вносите никаких изменений ни в один из каталогов.

Создается при инициализации репозитория.

Теперь создайте блокнот для репозитория. Позже вы можете отправить этот файл в репозиторий GitLab.

БЕСПЛАТНЫЙ тренинг по сертификации DevOps

Освойте основы DevOpsStart Learning

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

сенсорный input.txt

блокнот input.txt

Блокнот появится на экране.Введите что-нибудь внутри, затем сохраните и закройте.

Следующим шагом будет проверка статуса файла.

Это показывает, что файл еще не зафиксирован, и есть неотслеживаемые файлы. Неотслеживаемые файлы отображаются красным цветом.

Теперь добавьте файл в область подготовки с помощью следующей команды:

Следующим шагом является фиксация файла. Для фиксации используйте команду фиксации.

Еще раз проверьте состояние файла.

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

Теперь пора перенести блокнот в репозиторий GitLab.

Для этого перейдите в свой GitLab и скопируйте команду git remote origin, как показано ниже.

После этого вернитесь в Git Bash и вставьте команду.

Теперь используйте удаленную команду, а затем команду push, чтобы отправить файл в удаленный репозиторий.

git push -u origin master

Теперь перейдите в свой GitLab и проверьте, есть ли какие-либо дополнения к новому проекту, который вы изначально создали.

Вы видите, что там появляется блокнот. Теперь вы можете открыть и проверить содержимое блокнота.

Зарегистрируйтесь в программе DevOps Engineer Masters Program и научитесь работать с такими инструментами, как Docker, Git, Jenkins, Puppet & Nagios.

Особенности GitLab

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

Позволяет использовать мощные конвейеры CI / CD
Имеет встроенный реестр, который можно мгновенно развернуть без каких-либо настроек.
Прекрасно интегрируется с Kubernetes
Он может импортировать огромные проекты, а также экспортировать другие коды в проекте

Преимущества GitLab

GitLab предлагает ряд преимуществ для разработчиков.Вот некоторые из наиболее важных преимуществ Gitlab:

Очень простая установка
Удобный пользовательский интерфейс и инструменты
Позволяет неограниченное количество бесплатных частных репозиториев
Может интегрировать множество API и сторонних сервисов
Имеет очень надежную безотказную работу

Недостатки GitLab

GitLab также может иметь свою долю недостатков:

Пользовательский интерфейс может быть немного сложным для просмотра
Сам инструмент имеет ряд ошибок, которые могут сделать его немного небрежным

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

Хотите узнать больше?

Если вы хотите начать свою карьеру в DevOps, ознакомьтесь с нашей магистерской программой DevOps Engineer’s Program сегодня. В этой комплексной программе вы узнаете обо всех концепциях, инструментах и методах, позволяющих стать сертифицированным профессионалом DevOps — должность, которая востребована в современном быстро меняющемся цифровом мире.

Начало работы с GitLab: Руководство для начинающих | Мари Лефевр

Концепция Git

Прежде всего: что такое Git? Как сказано на веб-сайте git, « Git — это бесплатная распределенная система управления версиями с открытым исходным кодом , предназначенная для быстрой и эффективной обработки всего, от небольших до очень крупных проектов».Эта система традиционно используется для координации работы между программистами, которые совместно разрабатывают исходный код во время разработки программного обеспечения. Он позволяет отслеживать изменения в любом наборе файлов, поэтому он очень важен для любого совместного проекта, основанного на общей версии кода. Цели Git включают скорость, целостность данных и поддержку распределенных нелинейных рабочих процессов (тысячи параллельных ветвей, работающих в разных системах).

Конкретно это означает, что два разных человека могут работать над одним и тем же кодом, не мешая друг другу прогресса. .Для этого каждый человек будет работать над своей собственной веткой , которая является копией основного кода, расположенного в ветке «master». При сохранении модификации каждый пользователь фиксирует своих изменений и объясняет, что было изменено, в так называемом запросе на слияние . Вот визуализация, чтобы лучше понять логику ветвей Git:

GitLab: онлайн-платформа, основанная на Git и разработанная для организаций

Хотя Git можно использовать непосредственно на компьютере каждого пользователя — через терминал компьютера или Git Клиент GUI, такой как Sublime Merge, например — GitLab — это онлайн-платформа, где все действия могут быть выполнены в вашем браузере .Как описано на веб-сайте GitLab, это «программное обеспечение с открытым исходным кодом для совместной работы над кодом». Создание учетной записи GitLab бесплатно, поэтому, если вы используете ее в корпоративном контексте, администратор проекта добавит вас в соответствующие проекты компании. Это означает, что вы потенциально можете работать в GitLab с одной и той же учетной записью как для профессиональных, так и для личных проектов (в зависимости от адреса электронной почты, который вы используете для создания учетной записи).

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

Кроме того, GitLab представляет собой «полную платформу DevOps», поскольку он позволяет организациям гораздо больше, чем просто отслеживать изменения, вносимые пользователями в основной код.GitLab также включает инструменты для тестирования фрагментов кода и позволяет развертывать код в производственной среде (когда код фактически применяется и используется внешними инструментами, полагающимися на него). Я не буду здесь вдаваться в подробности, так как я хочу рассказать об основных возможностях GitLab для новичков в мире разработки программного обеспечения.

В чем основные отличия? Полное руководство

Эта статья предоставлена вам Usersnap. Usersnap помогает вам общаться визуально. И что самое лучшее? Он соединяется с GitLab и GitHub.Получите 15-дневную бесплатную пробную версию здесь.

Службы управления репозиториями

Version Control являются ключевым компонентом рабочего процесса разработки программного обеспечения. В последние несколько лет GitHub и GitLab позиционировали себя как удобных помощников для разработчиков, особенно при работе в больших командах.

В последнем выпуске GitLab 10.0 GitLab сделал большой шаг вперед от управления кодом к развертыванию и мониторингу. GitLab называет это Complete DevOps. Они нацелены на весь рынок разработки, развертывания и DevOps программного обеспечения.

Это означает, что, говоря о различиях и сходстве GitLab и GitHub, нам нужно выйти за рамки репозиториев кода и взглянуть на весь процесс.

Готовы?

Git объяснил

И GitLab, и GitHub являются веб-репозиториями Git.

Что такое репозиторий Git?

Целью Git является управление проектами разработки программного обеспечения и их файлами, поскольку они меняются с течением времени. Git хранит эту информацию в структуре данных, называемой репозиторием.

Такой репозиторий git содержит набор объектов фиксации и набор ссылок на объекты фиксации.

Репозиторий git — это центральное место, где разработчики хранят, совместно используют, тестируют и совместно работают над веб-проектами.

Больше, чем репозиторий Git: как завершить DevOps

В настоящее время GitLab и GitHub — это больше, чем «просто» репозитории git для разработчиков.

GitLab сообщает об их недавнем анонсе Complete DevOps vision:

Теперь мы делаем еще один шаг вперед, чтобы объединить разработку и операции в одном пользовательском интерфейсе.

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

Основы GitHub и GitLab

Начнем с основ. GitHub — это платформа для размещения репозиториев на основе Git с 40 миллионами пользователей (январь 2020 г.), что делает ее крупнейшим исходным кодом в мире. Изначально GitHub был запущен в 2008 году и был основан Томом Престоном-Вернером, Крисом Ванстратом и П.Дж. Хайеттом.

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

Публичные репозитории на GitHub часто используются для обмена программным обеспечением с открытым исходным кодом. Помимо базового репозитория кода, GitHub можно использовать для отслеживания проблем, документации и вики.

Всего в 2017 году на GitHub было создано более 100 миллионов репозиториев.

Наиболее часто используемые теги репозитория на Github.com

Подобно GitHub, GitLab — это менеджер репозитория, который позволяет командам совместно работать над кодом. Написанный на Ruby and Go, GitLab предлагает некоторые функции для отслеживания проблем и управления проектами, аналогичные GitHub.

Основанная Дмитрием Запорожцем и Валерием Сизовым в 2011 году, в GitLab работает более 1300 человек, и, по данным Википедии, у GitLab 100000 пользователей (март 2017 года) и используется такими предприятиями, как IBM, Sony и NASA.

Ключевые различия и сходства: GitLab против GitHub

Согласно различным источникам и нашему собственному опыту, мы выявили следующие ключевых отличий , которые вы должны знать при принятии решения: GitLab vs GitHub .

Уровни аутентификации

С помощью GitLab вы можете устанавливать и изменять разрешения людей в соответствии с их ролью. В GitHub вы можете решить, получит ли кто-то доступ для чтения или записи в репозиторий.

С помощью GitLab вы можете предоставить доступ к системе отслеживания проблем (например), не давая разрешения на исходный код. Это, очевидно, отлично подходит для больших команд и предприятий с участниками, основанными на ролях.

GitLab CI против действий GitHub

Одно из больших различий между GitLab и GitHub — это встроенная функция непрерывной интеграции / доставки GitLab.CI — это огромная экономия времени для многих команд разработчиков и отличный способ контроля качества (никому не нравятся запросы на вытягивание, которые нарушают работу вашего приложения).

GitLab предлагает свой собственный CI бесплатно. Нет необходимости использовать внешнюю службу CI. И если вы уже привыкли к внешнему CI, вы, очевидно, можете интегрироваться с Jenkins, Codeship и другими.

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

Operations Dashboard, источник: gitlab.com

GitLab CI предлагает Auto DevOps, который автоматически запускает CI / CD без реальной настройки человеком.

Но на самом деле в каждом проекте должен быть запущен какой-то CI. Итак, почему бы нам просто не определить, когда вы продвинули проект; мы просто построим его и пойдем и протестируем, потому что мы знаем, как проводить тестирование.
Марк Пундсак, источник: gitlab.com

Итак, как CI / CD работает во вселенной GitHub? GitHub выпустил Actions в конце 2019 года, который, по сути, позволяет вам писать задачи, которые автоматизируют и настраивают рабочий процесс разработки.Начать работу тоже можно бесплатно.

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

Загрузите бесплатно это пошаговое руководство по настройке конвейера CI / CD с GitLab, GitHub и Travis CI.

Отслеживание проблем

GitLab, так же как и GitHub, предоставляют простой инструмент отслеживания проблем, который позволяет вам одновременно изменять статус и исполнителя для нескольких проблем.

Оба являются отличными средствами отслеживания проблем, особенно когда они связаны с визуальным средством отслеживания ошибок, таким как Usersnap.Хотя вашим разработчикам по-прежнему нравится отличный интерфейс отслеживания проблем GitLab и GitHub, ваши тестировщики, коллеги и клиенты могут просто сообщать об ошибках через виджет Usersnap.

Виджет сообщений об ошибках Usersnap в действии

Отчеты об ошибках и отзывы пользователей могут автоматически отправляться на GitLab или GitHub. Или вы можете предварительно отфильтровать эти заявки в Usersnap и вручную отправить их в свой проект разработки.

Входящие отчеты об ошибках, отображаемые в вашем репозитории GitHub Входящие отчеты об ошибках, отображаемые в вашем репозитории GitLab

Импорт и экспорт

Размышляя о переходе на GitLab или GitHub, вы также должны учитывать затраты на установку и ресурсы, необходимые для начала работы.В связи с этим очень важна тема доступных функций импорта и экспорта.

GitLab предлагает подробную документацию о том, как импортировать ваши данные от других поставщиков, таких как GitHub, Bitbucket, в GitLab.

Импорт проектов от сторонних производителей, источник: gitlab.com

GitHub, с другой стороны, не предлагает такой подробной документации для наиболее распространенных репозиториев git. Однако GitHub предлагает использовать GitHub Importer, если у вас есть исходный код в Subversion, Mercurial, TFS и других.

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

Wiki и репозитории проектов
Загрузка проекта
Конфигурация, включая веб-перехватчики и службы
Проблемы с комментариями, запросы на слияние с различиями и комментариями, метки, этапы, фрагменты и другие объекты проекта

GitHub, с другой стороны , кажется более строгим, когда дело доходит до функций экспорта существующих репозиториев GitHub.

Интеграции

И GitLab, и GitHub предлагают широкий спектр сторонних интеграций. Интеграция вашей системы контроля версий с другими приложениями обогащает ваши рабочие процессы и может повысить продуктивность ваших разработчиков и тех, кто не является разработчиками.

Чтобы проверить, совместимы ли ваши любимые приложения с GitLab и GitHub, я рекомендую проверить документацию GitLab и GitHub.

Помимо доступных партнеров по интеграции, в мае 2017 года GitHub запустил свою торговую площадку GitHub, предлагающую вам избранные инструменты и приложения.

GitLab пошел по тому же пути и предлагает несколько интеграций для команд разработчиков и DevOps.

Сообщество GitHub

GitHub позиционирует себя среди своего сообщества разработчиков. И его популярность в основном обусловлена очень активным сообществом GitHub, состоящим из миллионов разработчиков. Вы можете обсудить проблемы и, возможно, узнать несколько неофициальных, но классных советов. С другой стороны, GitLab предпринял ряд замечательных действий, таких как проведение мероприятий сообщества и подключение участников с открытым исходным кодом.

Если вы ищете самое большое сообщество разработчиков, велики шансы, что GitHub — лучшее место.

GitLab Enterprise против GitHub Enterprise

На уровне предприятия вы должны учитывать дополнительные факторы при принятии информированного решения о том, использовать ли GitLab или GitHub.

GitHub очень популярен среди разработчиков, а за последние несколько лет он приобрел популярность и среди более крупных групп разработчиков и организаций.

Пользовательские корпоративные функции GitHub

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

Вот сравнение цен GitLab и GitHub.

В то время как корпоративный план GitHub начинается с 2500 долларов США на 10 пользователей в год (= 250 долларов США на пользователя), стартовый план GitLab составляет 39 долларов США на пользователя в год.

Характеристики	GitLab	GitHub
выпущено	Сентябрь 2011	Апрель 2008 г.
Бесплатные планы	Неограниченные публичные и частные репозитории	Бесплатно только для публичных репозиториев
Платные планы	От 39 долларов США за пользователя в год	Начинается с 84 долларов за пользователя в год
Особенности проверки кода	да	да
Вики	да	да
Отслеживание ошибок и проблем	да	да
Частный филиал	да	да
Система сборки	да	да (со сторонней службой)
Импорт проектов	да	№
Экспортные проекты	да	№
Учет времени	да	№
Веб-хостинг	да	да]
Самостоятельный хостинг	да	да (с корпоративным планом)
Популярность	546.000+ проектов	69.000.000+ проектов

Завершение.

Несомненно, GitHub по-прежнему остается самым популярным репозиторием git с наибольшим количеством пользователей и проектов. Однако GitLab отлично справляется со своей задачей, предлагая всем вашим командам разработчиков (и DevOps) отличные инструменты для более эффективных рабочих процессов.

Бонусный совет: получайте отзывы пользователей и отчеты об ошибках с помощью Usersnap

И последнее, но не менее важное: я хотел рассказать вам о Usersnap, нашем собственном инструменте визуальной обратной связи с пользователями и отслеживании ошибок, который используется такими компаниями, как Facebook и Microsoft.

И что самое приятное? Вы можете связать проблемы GitHub или GitLab с Usersnap, чтобы получать визуальные отчеты об ошибках, напрямую отправляемые в предпочитаемую вами систему.

Получайте отличные отзывы пользователей и отчеты об ошибках с помощью бесплатной пробной версии Usersnap.