Как пользоваться GitLab
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
Затем давайте создадим файл 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
Для отправки данных нужно ввести ваш логин и пароль на GitLab. Теперь, если вы обновите страницу репозитория на GitLab, то увидите там наш файл:
Важно отметить, что если удаленный репозиторий не пуст, то у вас не получиться так сделать. Вам нужно будет сначала скачать удаленный репозиторий, слить локальные изменения с ним, а потом уже отправить всё назад.
5. SSH ключи
Во время загрузки данных репозитория на GitLab нам нужно было ввести логин и пароль на сервере. Чтобы этого избежать можно использовать SSH ключи для авторизации. Сначала вам нужно создать такой ключ. Для этого откройте терминал и выполните:
Введите путь к файлу, куда нужно сохранить ключ, а пароль оставьте пустым. Будут созданы два файла — открытый ключ с расширением .pub и закрытый. Вам нужен открытый. Откройте его в текстовом редакторе и скопируйте его содержимое в буфер обмена:
Далее возвращайтесь к интерфейсу GitLab кликните по иконке профиля и выберите Settings:
Здесь на левой панели найдите пункт SSH Keys. В этом окне найдите поле Key и вставьте туда скопированный ключ. Далее сохраните изменения. Теперь ваш ключ добавлен:
Далее вернитесь в ваш репозиторий, найдите в правом верхнем углу кнопку Clone и кликните по ней. Нас интересует адрес Clone with SSH:
Возвращаемся к нашему локальному репозиторию, удаляем адрес https и добавляем ssh:
git remote remove origin git remote add origin git@gitlab.com: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
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 CE
В последнее время разработчики платного и даже бесплатного программного обеспечения закрывают доступ к своим продуктам пользователям и компаниям из России. А ведь для IТ-компаний проблемы с тем же трекером или хранилищем репозиториев грозят частичной или полной остановкой работы. В зоне повышенного риска — распределенные команды, для которых данные системы — место силы всей компании.
На связи Саша Хрущев, технический директор IT-компании WINFOX. Рассказываю, как мы быстренько развернули свое независимое локальное хранилище репозиториев в GitLab CE, сколько времени это заняло и какие особенности вам нужно учитывать при переезде, чтобы все прошло гладко.
Как все началось
В один прекрасный летний день Atlassian не дал нам продлить платную подписку на наш облачный Bitbucket. Из-за этого наши разработчики больше не могли пушить свои изменения и создавать merge-реквесты. Все это грозило замедлить нашу работу на неопределенный срок.
Экран блокировки доступа в Atlassian
Подумав про себя «А нас-то за что. », мы бросились искать варианты продления подписки. Это оказалось напрасно: варианты с VPN и прочими хитростями не сработали, и мы просто потратили наше драгоценное время впустую. Плюс все понимали: даже если сейчас этот фокус прокатит, то уже завтра ситуация гарантированно повторится.
Решение нужно было принимать очень быстро, так как любая проволочка грозила прямыми финансовыми потерями.
Мы поискали различные облачные альтернативы Bitbucket, включая отечественные облачные репозитории. Изучив доступные сервисы, поняли, что при выборе любого из этих вариантов сохраняется риск недоступности сервиса в случае каких-либо проблем. То есть мы рискуем снова потерять возможность пушить туда свои изменения, а то и доступ ко всему репозиторию.
В общем, мы решили разворачивать свое локальное хранилище репозиториев и сделать его полностью независимым от действий сторонних компаний.
Почему мы выбрали GitLab CE
Самое нормальное бесплатное решение, которое есть на рынке и которое обладает всем необходимым доступным функционалом, — это GitLab CE. Под всем необходимым доступным функционалом мы понимаем следующее:
безлимит репозиториев Git как по количеству, так и размерам;
интеграции с трекерами и прочими корпоративными системами;
вменяемый процесс бэкапирования.
На следующий день после блокировки доступа к Bitbucket мы начали переезд на GitLab CE. Об этом по порядку.
Этап 1. Установка
Прежде всего надо было установить GitLab на корпоративном сервере. Несмотря на то, что GitLab CE имеет достаточно подробную инструкцию по установке, в процессе установки возникли некоторые сложности. Вот главное, на что рекомендую обратить внимание при установке.
Конфигурация сервера. Сервер должен быть не менее 8 Гб оперативной памяти и 2 ядра процессора с нормальным большим дисковым хранилищем. Попытки экономии здесь обязательно выйдут боком — если не сразу, так потом.
Домен или поддомен. Они нужны изначально.
Установка на Ubuntu. Мы ставили GitLab на Ubuntu, использовали эту подробную инструкцию по установке.
Установить и настроить GitLab в Ubuntu 18.04 поможет готовая инструкция на DigitalOcean Community
Https в external_url. Обязательно ставьте https в external_url, так как GitLab умеет самостоятельно выпускать и использовать сертификаты от Let’s Encrypt. Если поставить https в external_url при установке, проблем в дальнейшем будет меньше.
Конфигурация ОС. Если локали на Linux не скофигурены должным образом, в процессе установки будут появляться ошибки. А именно невозможность поднять базу данных Postgres, локаль которой по умолчанию UTF-8.
Такую ошибку вы можете увидеть, если локали на Linux сконфигурированы неверно
Если вы столкнулись с подобным, помогут уже расписанные решения. Вот одно из таких решений.
Этап 2. Конфигурация
После установки настало время сконфигурировать. Немного расскажу, как делать изначальную настройку GitLab и как ее делали мы.
Главное на этом этапе — минимизировать время, за которое команда сможет полностью возобновить работы на новых репозиториях.
Регистрация. Чтобы ускорить регистрацию всех членов команды, мы оставили открытой регистрацию на главной странице.При этом мы ограничили возможности регистрации по строго определенному доменному имени e-mail. Таким образом, вся команда зарегистрируется сама, нам же останется сделать аппрув и доступы, после чего открытую регистрацию можно закрывать.
Процесс регистрации на GitLab CE
Импорт репозиториев. Пока команда регистрируется, импортируем репозитории. Этот процесс специфический для каждого из облачных репозиториев, но он подробно описан в документации для GitLab.
Большая часть репозиториев нормально импортируется автоматом, однако GitLab автоматически неправильно ставит имена репозиториев в которых есть «_» (нижнее подчеркивание). В сложных именах репозиториев вместо этого символа появляется пробел и система не может импортировать эти репозитории. Для таких репозиториев надо будет руками ввести нормальное имя, что немного задержит автоматический импорт.
Еще одна проблема, которая у нас всплыла, — не все репозитории скопировались нормально. Из более чем 140 репозиториев один скопировался не полностью, поэтому пришлось вручную переносить ветки. Это затянуло процесс импорта.
Процесс импорта репозиториев описан в инструкции на сайте GitLab Docs
Этап 3. Настройка
После импорта репозиториев не стоит сразу раздавать доступы и приступать к работе. Если вам надо настроить вебхуки или прочие интеграции, самое время это сделать.
Группировка вебхуков. Для правильной настройки вебхуков надо правильно сгруппировать проекты.
В нашем процессе разработки вебхуки разделены по платформам/стеку. У других команд, например, они сгруппированы по проектам. Соответственно, надо сгруппировать репозитории. При этом путь к ним изменится. Именно поэтому до группировки не стоит раздавать доступы и скидывать URL репозиториев разработчикам, иначе им придется повторно менять эти URL у себя.
Раздача доступов. Как только группировка закончена, можно возобновлять работу с репозиторием и раздавать разработчикам доступы.
Можно считать, что с этого момента работа команды продолжится в нормальном режиме. Нам же ничто не мешает продолжать настройку.
Настройка вебхуков. После того, как мы перенесли все репозитории и раздали доступы, переходим к настройке GitLab, то есть настройке вебхуков.
У нас вебхуки используются для информирования в каналах дискорда о коммитах, пушах и merge-реквестах. Соответствующим образом настраиваются вебхуки для групп репозиториев. Кстати, в Bitbucket Cloud сделать это без определенной прослойки у нас не получилось, а в GitLab CE это без проблем заработало из коробки.
Настройка пайплайнов. Теперь настраиваем пайплайны CI-CD на новом месте. Это долгий процесс — у нас ушла почти неделя.
Настройка других полезных фич. Далее мы настроили несколько полезных вещей, которых не было ранее. Вот они:
уведомление руководства о событиях в репозиториях: все коммиты, мердж-реквесты, операции с ветками уходят письмами руководству компании;
интеграция с Sentry: получение инцидентов из веб-приложений в реальном времени и заведение их автоматом в GitLab;
заведение инцидентов через почту: аналогично Sentry, но инциденты создаются из писем на определенный ящик.
На этом переезд на Gitlab CE закончен.
Бонусом скажу про плюсы этого инструмента и покажу примерный roadmap переезда исходя из опыта.
Плюсы переезда на GitLab CE
Среди главных плюсов — экономия, независимость и широкие возможности кастомизации.
Экономия (внезапно). Мощный сервер под GitLab CE обошелся нам в 1,5 раза дешевле, чем мы платили за Bitbucket Cloud, а у нас не такая уж большая команда — GitLab используют 20 сотрудников. Для большой команды разница будет еще существеннее.
Независимость от политики и прочих мировых событий. GitLab CE — независимый веб-инструмент. А если хотите максимально минимизировать риски, можно выделить железный сервер в своем дата-центре под это дело. (Правда, с учетом реалий современного мира все равно ничто не гарантирует сохранность и доступность этого дата-центра).
Широчайшие возможности кастомизации. GitLab CE можно гибко настроить под себя, начиная от простой настройки до дописывания интеграционных прослоек. При этом возможностей гораздо больше, чем у самых дорогих облачных решений, например Bitbucket и GitHub.
Это просто приятно)
Примерный roadmap переезда на GitLab CE
Я посчитал, сколько времени занял переезд у нас. Это поможет вам спланировать время в своей команде.
Мы посчитали, сколько времени занимает переезд на GitLab CE
Важно. Чтобы возобновить работу команды на новых репозиториях, вам, скорее всего, потребуется 5-6 часов или 2-3 часа при хорошем раскладе.
Полностью продублировать функционал своего предыдущего хранилища репозиториев, включая вебхуки и интеграции, вы сможете в течение 1-2 недель.
Что дальше
На очереди — дальнейшее изучение возможностей GitLab CE и настройка новых интеграций, например интеграции с таск-трекерам, базами знаний, мониторингом Prometeus и рассылкой уведомлений через Pushover.
Если интересно про это почитать, пишите в комментариях — буду рад поделиться опытом.
Import Project to New Repo (GitHub to GitLab) — Part 1
Hey, what is going on, guys! Today, I want to talk about How to import a project to a new repository from GitHub to GitLab. Let’s jump in now!
The Purpose of Import Existed Project to New Repo
Here are the purpose:
1. Saving all the history you have been working, commits, merge, and more.
2. You do not have to clone your repo again and add a new remote to your project.
3. Save your branch history. It is worth when you have a lot of branches.
When Did I Import Project to New Repo
I have a case like this, when I start working in a company, the company has its own repository and I start working on my project at my own repository, not in the company repository. After I worked in my own repository (GitHub), the company asked me to switch the project repo to company repo (GitLab). I said, “What am I suppose to do? I already have 10 branches and 300 commits on it, I’m gonna lose it all, yeah?”. But, I searched in Google, that GitLab has a feature that can import a project from another repository without losing your working history. I mean, wow it feels great that I didn’t have to start commit from 0 and start making branches.
Curious about how to do it? Check it out!
Import Existing Project from GitHub to GitLab
To import it from GitHub to GitLab, it is simple. Just follow this step:
- Make sure you have GitLab account. If you do not have it already, you should visit https://gitlab.com/users/sign_in#register-pane. You will see a form like below. But if you have the account already, just choose Sign in.
2. If you already have an account, you will see your project list. Click New project.
3. After you click New project, you will see an interface like this. Choose Import project.
4. You will see the menu like below. Choose Repo by URL. Do not close the tab; just left it for a moment.
I have repo like this on GitHub, just for an example. The URL is “https://github.com/youraccount/someproject”; you can copy this link.
5. Back to your GitLab page, copy your GitHub repo URL to this form. The username and password form is optional, you can fill or leave it. I never filled it by the way. Just fill the form that you need.
6. Click Create Project at the bottom of the page. If you have already imported it, you will see a message that your project has been imported to a new repository; YEAY!
That’s it for now. If you have any problem, put your problem in the comment section, I will response to it.
Next, I am going to show you all How to Import Project From GitLab to GitHub.
Thank you.
Huda Prasetyo is an intern at GITS Indonesia as back-end developer. He is currently a student at Vocational High School MedikaCom Bandung and a NodeJS enthusiast.
Name already in use
gitlabhq / doc / gitlab-basics / start-using-git.md
- Go to file T
- Go to line L
- Copy path
- Copy permalink
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
Command line Git (FREE)
Git is an open-source distributed version control system. GitLab is built on top of Git.
You can do many Git operations directly in GitLab. However, the command line is required for advanced tasks, like fixing complex merge conflicts or rolling back commits.
If you’re new to Git and want to learn by working in your own project, learn how to make your first commit.
For a quick reference of Git commands, download a Git Cheat Sheet.
For more information about the advantages of working with Git and GitLab:
- Watch the GitLab Source Code Management Walkthrough video.
- Learn how GitLab became the backbone of the Worldline development environment.
To help you visualize what you’re doing locally, you can install a Git GUI app.
Choose a terminal
To execute Git commands on your computer, you must open a terminal (also known as command prompt, command shell, and command line). Here are some options:
- For macOS users:
- Built-in Terminal. Press ⌘ command + space and type terminal . . You can integrate it with Zsh and Oh My Zsh for color highlighting and other advanced features.
- Built-in command line. On the Windows taskbar, select the search icon and type cmd . .
- Git Bash. It is built into Git for Windows.
- Built-in Linux Terminal.
Confirm Git is installed
You can determine if Git is already installed on your computer by opening a terminal and running this command:
If Git is installed, the output is:
If your computer doesn’t recognize git as a command, you must install Git.
To start using Git from your computer, you must enter your credentials to identify yourself as the author of your work. The username and email address should match the ones you use in GitLab.
In your shell, add your user name:
Add your email address:
To check the configuration, run:
The —global option tells Git to always use this information for anything you do on your system. If you omit —global or use —local , the configuration applies only to the current repository.
You can read more on how Git manages configurations in the Git configuration documentation.
Choose a repository
Before you begin, choose the repository you want to work in. You can use any project you have permission to access on GitLab.com or any other GitLab instance.
To use the repository in the examples on this page:
- Go to https://gitlab.com/gitlab-tests/sample-project/.
- In the upper-right corner, select Fork.
- Choose a namespace for your fork.
The project becomes available at https://gitlab.com/<your-namespace>/sample-project/ .
You can fork any project you have access to.
Clone a repository
When you clone a repository, the files from the remote repository are downloaded to your computer, and a connection is created.
This connection requires you to add credentials. You can either use SSH or HTTPS. SSH is recommended.
Clone with SSH when you want to authenticate only one time.
Authenticate with GitLab by following the instructions in the SSH documentation.
Go to your project’s landing page and select Clone. Copy the URL for Clone with SSH.
Open a terminal and go to the directory where you want to clone the files. Git automatically creates a folder with the repository name and downloads the files there.
Run this command:
To view the files, go to the new directory:
Clone with HTTPS
Clone with HTTPS when you want to authenticate each time you perform an operation between your computer and GitLab.
Go to your project’s landing page and select Clone. Copy the URL for Clone with HTTPS.
Open a terminal and go to the directory where you want to clone the files.
Run the following command. Git automatically creates a folder with the repository name and downloads the files there.
GitLab requests your username and password.
If you have enabled two-factor authentication (2FA) on your account, you cannot use your account password. Instead, you can do one of the following:
-
with read_repository or write_repository permissions.
- Install Git Credential Manager.
If you have not enabled 2FA, use your account password.
To view the files, go to the new directory:
NOTE: On Windows, if you enter your password incorrectly multiple times and an Access denied message appears, add your namespace (username or group) to the path: git clone https://namespace@gitlab.com/gitlab-org/gitlab.git .
Clone using a token
Clone with HTTPS using a token if:
- You want to use 2FA.
- You want to have a revocable set of credentials scoped to one or more repositories.
You can use any of these tokens to authenticate when cloning over HTTPS:
Convert a local directory into a repository
You can initialize a local folder so Git tracks it as a repository.
Open the terminal in the directory you’d like to convert.
Run this command:
A .git folder is created in your directory. This folder contains Git records and configuration files. You should not edit these files directly.
Add the path to your remote repository so Git can upload your files into the correct project.
You add a «remote» to tell Git which remote repository in GitLab is tied to the specific local folder on your computer. The remote tells Git where to push or pull from.
To add a remote to your local copy:
In GitLab, create a project to hold your files.
Visit this project’s homepage, scroll down to Push an existing folder, and copy the command that starts with git remote add .
On your computer, open the terminal in the directory you’ve initialized, paste the command you copied, and press enter :
View your remote repositories
To view your remote repositories, type:
The -v flag stands for verbose.
Download the latest changes in the project
To work on an up-to-date copy of the project, you pull to get all the changes made by users since the last time you cloned or pulled the project. Replace <name-of-branch> with the name of your default branch to get the main branch code, or replace it with the branch name of the branch you are currently working in.
When you clone a repository, REMOTE is typically origin . This is where the repository was cloned from, and it indicates the SSH or HTTPS URL of the repository on the remote server. <name-of-branch> is usually the name of your default branch, but it may be any existing branch. You can create additional named remotes and branches as necessary.
You can learn more on how Git manages remote repositories in the Git Remote documentation.
A branch is a copy of the files in the repository at the time you create the branch. You can work in your branch without affecting other branches. When you’re ready to add your changes to the main codebase, you can merge your branch into the default branch, for example, main .
Use branches when you:
- Want to add code to a project but you’re not sure if it works properly.
- Are collaborating on the project with others, and don’t want your work to get mixed up.
A new branch is often called feature branch to differentiate from the default branch.
Create a branch
To create a feature branch:
Branch names cannot contain empty spaces and special characters. Use only lowercase letters, numbers, hyphens ( — ), and underscores ( _ ).
Switch to a branch
All work in Git is done in a branch. You can switch between branches to see the state of the files and work in that branch.
To switch to an existing branch:
For example, to change to the main branch:
To view the differences between your local unstaged changes and the latest version that you cloned or pulled:
View the files that have changes
When you add, change, or delete files or folders, Git knows about the changes. To check which files have been changed:
Add and commit local changes
When you type git status , locally changed files are shown in red. These changes may be new, modified, or deleted files or folders.
To stage a file for commit:
Repeat step 1 for each file or folder you want to add. Or, to stage all files in the current directory and subdirectory, type git add . .
Confirm that the files have been added to staging:
The files should be displayed in green text.
To commit the staged files:
Stage and commit all changes
As a shortcut, you can add all local changes to staging and commit them with one command:
Send changes to GitLab.com
To push all local changes to the remote repository:
For example, to push your local commits to the main branch of the origin remote:
Sometimes Git does not allow you to push to a repository. Instead, you must force an update.
Delete all changes in the branch
To discard all changes to tracked files:
This action removes changes to files, not the files themselves. Untracked (new) files do not change.
Unstage all changes that have been added to the staging area
To unstage (remove) all files that have not been committed:
Undo most recent commit
To undo the most recent commit:
This action leaves the changed files and folders unstaged in your local repository.
WARNING: A Git commit should not be reversed if you already pushed it to the remote repository. Although you can undo a commit, the best option is to avoid the situation altogether by working carefully.
You can learn more about the different ways Git can undo changes in the Git Undoing Things documentation.
Merge a branch with default branch
When you are ready to add your changes to the default branch, you merge the feature branch into it:
In GitLab, you typically use a merge request to merge your changes, instead of using the command line.
To create a merge request from a fork to an upstream repository, see the forking workflow.
Advanced use of Git through the command line
For an introduction of more advanced Git techniques, see Git rebase, force-push, and merge conflicts.
Synchronize changes in a forked repository with the upstream
To create a copy of a repository in your namespace, you fork it. Changes made to your copy of the repository are not automatically synchronized with the original. To keep the project in sync with the original project, you need to pull from the original repository.
You must create a link to the remote repository to pull changes from the original repository. It is common to call this remote repository the upstream .
You can now use the upstream as a <remote> to pull new updates from the original repository, and use the origin to push local changes and create merge requests.