гит может отслеживать изменения файлов в дирректории с логированием
Хранит проект в облаке с доступом для остальной команды
репозиторий — папка с файлами за которой следит гит
гит вносит изменения только после явной команды
если мы клонировали себе репозиторий с облака, гит сразу за ним следит
перед комитом мы сначала выбираем файлы которые хотим сохранить и уже после этого создаем слепок файлов
после комита для него присваивается номер (хэш комита), мы можем вернуться к предыдущей версии по номеру комита
Допустим мы все держали это локально, и теперь хотим закинуть в облако
мастер ветка самая главная и есть всегда
остальные ветки это истории изменений с определенным именем
Слияние веток
первый варик это merge напимер из какой то ветки в мастер, применит все изменения разом в виде всего одного комита (а не истории этих комитов)
второй варик это rebase слияние веток будет уже с историей изменений той ветки которая сливается с мастер веткой например
GIT FLOW
Pull request или же Merge request
Чтобы не навалить кринжа, лучше сделать запрос на слияние, можно или баги есть
Черри пик
Существует для того чтобы взять какой то конкретный комит из ветки и использовать именно его, или только его запушить в мастер (ну мало ли)
Гит реверт и гит ресет
первый возвращает нас к нужному комиту по его хешу
ресет удаляет сам комит и его изменения, удаляется все от текущей версии до того комита который указан
софт ресет просто уберет сами комиты но файлы то не изменятся и файлы в индекс попадают готовые для комита
хард вариант стирает все до конца и ничего в индекс гита для комита не попадает
GitLab — это сервис для хранения кода, управления версиями и совместной разработки программного обеспечения. Устанавливается на собственных серверах
Система контроля версий Git используется для хранения промежуточных версий кода. Например, когда разработчик вносит в него изменения или добавляет новые части, то в Git он делает это с помощью коммитов.
Коммит (commit) — это пакет изменений, хранящий информацию с добавленными, отредактированными или удалёнными файлами кода. Благодаря этому основной код проекта всегда можно вернуть в работоспособное состояние, восстановив его прошлые версии.
Репозиторий. Место, где хранится код и дополнительные файлы, необходимые для его работы или вёрстки окон приложения: иконки, картинки и так далее. Репозиторий похож на обычную папку на компьютере, только с дополнительными функциями. Например, у каждого файла, который он хранит, есть история изменений.
Ветки (branch). Это параллельные линии разработки, которые существуют независимо друг от друга. В Git-системах разработчики пишут код в отдельных ветках, избегая таким образом конфликтов между вносимыми изменениями.
Когда бэкендер, фронтендер или другой специалист завершает работу над кодом в своей ветке, он создаёт запрос на слияние (merge request) с главной веткой (master или main), где находится основной код программы, чтобы перенести туда свои изменения.
Слияние — это процесс объединения двух или более веток в одну.
Другие разработчики могут оценить изменения и прокомментировать их. После тестирования и утверждения со стороны сеньора или тимлида запрос на слияние выполняется. В GitLab можно настроить процесс разработки так, чтобы изменения автоматически вносились в основную ветку при выполнении определённых условий, например после успешного прохождения тестов.
Тестирование кода
GitLab автоматизирует процессы тестирования при внесении любого изменения в код. Например, когда в проект добавляют новую функцию или изменяют старую, GitLab отправляет её в центральный репозиторий, где автоматически запускается тестирование.
Обычно этот процесс устроен следующим образом:
- Система проверяет код на ошибки компиляции.
- После этого запускаются тесты, написанные разработчиками: модульные — для проверки отдельных частей кода, интеграционные, проверяющие работу нового кода со старым, и другие. Цель всех тестов — убедиться, что новые изменения не ломают существующую функциональность приложения.
- Разработчик получает отчёт о пройденных тестах и при необходимости дорабатывает код. Когда все необходимые изменения будут внесены, GitLab интегрирует их в основной репозиторий проекта.
Сборка проекта
В GitLab есть репозитории контейнеров — автономных исполняемых пакетов, включающих в себя всё необходимое для работы приложения: библиотеки, файлы конфигураций и другое. Благодаря этому они запускаются в любой системе, вне зависимости от её окружения. Контейнеры создаются, развёртываются и управляются на платформе Docker.
В репозитории проекта можно хранить разные версии контейнеров для своего приложения и настроить их автоматическое обновление при изменении кода.
Релиз приложения
Встроенные средства continuous integration (CI) и continuous deployment (CD) автоматизируют весь процесс от сборки кода до загрузки приложения или его новой версии в среду выполнения: на веб-сервер, мобильное устройство или другую платформу.
Разработчик может определить тип окружения, например, выбрав продакшен-сервер, и автоматически развёртывать приложение в нём после тестирования.
В GitLab встроено несколько вариантов развёртывания «из коробки». Их выбирают в зависимости от задач:
- Сине-зелёное развёртывание (blue-green deployment). Используется две среды: рабочая («синяя») и тестовая («зелёная») — для проверки работы приложения после внесения изменений. Когда новую версию кода проверили, она становится «зелёной».
- Канареечное развёртывание (canary deployment). Сначала новая версия приложения разворачивается для небольшой части пользователей. Так её тестируют в реальных условиях, ограниченной аудитории, а затем становится основной для всех.
- Плавное развёртывание (rolling deployment). Приложение заменяется новой версией без прерывания работы. Если у команды несколько серверов, она обновляет код на одном из них, затем на следующем и так далее.
Эти стратегии снижают риски, возникающие при установке новых версий приложения. Например, связанные с его несовместимостью с конкретными пользовательскими устройствами. В случае сине-зелёного или канареечного развёртывания можно быстро откатиться к стабильной версии приложения.
И это не всё. В GitLab есть готовые шаблоны CI/CD templates. Это наборы инструкций или конфигураций для автоматизированной сборки, тестирования и развёртывания кода. Вместо того чтобы каждый раз создавать конфигурацию с нуля, разработчики могут использовать готовый шаблон и настроить его параметры для своего приложения.
Мониторинг
GitLab собирает различные метрики процесса CI/CD и производительности приложения: время сборки, процент успешного прохождения тестов, количество выявленных ошибок и другие. Если их не хватает, то можно интегрировать сторонние инструменты мониторинга, например Prometheus или Grafana.
По сути создано для тихого тестирования. Решил ты запушить свои поделки, а гитлаб не пропустит пока не будут пройдены все необходимые тесты
