vault backup: 2026-05-02 23:05:27
This commit is contained in:
Dmitry
@@ -0,0 +1,85 @@
|
||||
---
|
||||
status: seed
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- git
|
||||
- vcs
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-02
|
||||
title: Git
|
||||
---
|
||||
|
||||
# Git
|
||||
|
||||
**Git** — распределённая система контроля версий, разработанная Линусом Торвальдсом в 2005 году.
|
||||
|
||||
Git используется для управления историей изменений исходного кода, командной разработки и организации процессов доставки ПО. В [[DevOps - основы]] Git относится к базовым инструментам контроля версий.
|
||||
|
||||
## Зачем нужен Git
|
||||
|
||||
- хранит историю изменений проекта;
|
||||
- позволяет работать с ветками и объединять изменения;
|
||||
- поддерживает распределённую модель разработки;
|
||||
- помогает проводить code review и восстановление предыдущих состояний кода;
|
||||
- интегрируется с платформами вроде [[Gitlab]] и CI/CD.
|
||||
|
||||
## Преимущества
|
||||
|
||||
### Производительность
|
||||
|
||||
Git оптимизирован для локальных операций: большинство действий выполняется без обращения к удалённому серверу. История проекта хранится как набор объектов, связанных с содержимым файлов и метаданными версий.
|
||||
|
||||
### Безопасность
|
||||
|
||||
Git использует хеширование объектов, что помогает контролировать целостность истории изменений. Это защищает проект от незаметной подмены данных в истории.
|
||||
|
||||
### Гибкость
|
||||
|
||||
Git поддерживает разные модели разработки: от простой работы в одной ветке до сложных процессов с релизными, функциональными и hotfix-ветками.
|
||||
|
||||
## Базовые сущности
|
||||
|
||||
- **commit** — зафиксированное состояние изменений;
|
||||
- **branch** — ветка разработки;
|
||||
- **merge** — объединение веток;
|
||||
- **diff** — сравнение изменений между состояниями проекта.
|
||||
|
||||
Практические команды вынесены в заметку [[Основные команды git]].
|
||||
|
||||
## GitFlow
|
||||
|
||||
**GitFlow** — модель ветвления, где используются основные ветки и временные ветки для разработки функциональности.
|
||||
|
||||
Основные ветки:
|
||||
|
||||
- `main` — официальная история релизов;
|
||||
- `release` — подготовка готового функционала к выпуску;
|
||||
- `develop` — основная ветка разработки;
|
||||
- `feature` — разработка отдельной функциональности.
|
||||
|
||||
Когда в `develop` накоплен достаточный объём изменений, создаётся `release`-ветка. После тестирования она сливается в `main` и обратно в `develop`.
|
||||
|
||||
![[Pasted image 20260430152221.png|597]]
|
||||
|
||||
Недостатки GitFlow:
|
||||
|
||||
- не всегда хорошо сочетается с CI/CD;
|
||||
- избыточен для проектов с частыми релизами;
|
||||
- может усложнять историю слияний.
|
||||
|
||||
## Trunk Based Development
|
||||
|
||||
**Trunk Based Development (TBD)** — модель разработки, где основная работа ведётся вокруг одной главной ветки, называемой `trunk`.
|
||||
|
||||
Идея TBD: чаще интегрировать изменения в основную ветку, уменьшать долгоживущие ветки и поддерживать возможность выпуска релиза в любой момент.
|
||||
|
||||
![[Pasted image 20260430153712.png]]
|
||||
|
||||
TBD лучше сочетается с CI/CD-процессами, потому что уменьшает риск крупных конфликтов слияния и ускоряет обратную связь от сборок и тестов.
|
||||
|
||||
## Связанные заметки
|
||||
|
||||
- [[Основные команды git]]
|
||||
- [[Gitlab]]
|
||||
- [[DevOps - основы]]
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
status: seed
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
- git
|
||||
- cicd
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-02
|
||||
title: Gitlab
|
||||
---
|
||||
|
||||
# Gitlab
|
||||
|
||||
**Gitlab** — веб-платформа для управления репозиториями, командной разработкой и CI/CD-процессами поверх [[Git]].
|
||||
|
||||
Gitlab можно использовать как облачный сервис или развернуть на собственном сервере.
|
||||
|
||||
## Возможности
|
||||
|
||||
Gitlab позволяет:
|
||||
|
||||
- создавать, изменять и удалять репозитории;
|
||||
- управлять пользователями и правами доступа;
|
||||
- проводить code review;
|
||||
- настраивать проверки качества кода;
|
||||
- автоматизировать сборку, тестирование и доставку через CI/CD;
|
||||
- отслеживать задачи, релизы, метрики и состояние приложений.
|
||||
|
||||
## Gitlab в DevOps
|
||||
|
||||
В [[DevOps - основы]] Gitlab относится к инструментам CI/CD и командной разработки.
|
||||
|
||||
Gitlab помогает связать несколько процессов:
|
||||
|
||||
- управление исходным кодом через [[Git]];
|
||||
- review изменений;
|
||||
- автоматическое тестирование;
|
||||
- релизный цикл;
|
||||
- проверки безопасности;
|
||||
- наблюдаемость и сбор метрик.
|
||||
|
||||
## Работа с кодом
|
||||
|
||||
Gitlab поддерживает разные модели управления исходным кодом: GitFlow, Trunk Based Development и другие.
|
||||
|
||||
Основная работа ведётся через проекты, репозитории, ветки, коммиты и merge request. Практические операции с локальным репозиторием описаны в [[Основные команды git]].
|
||||
|
||||
## Связанные заметки
|
||||
|
||||
- [[Git]]
|
||||
- [[Основные команды git]]
|
||||
- [[DevOps - основы]]
|
||||
@@ -0,0 +1,92 @@
|
||||
---
|
||||
status: seed
|
||||
type: guide
|
||||
tags:
|
||||
- devops
|
||||
- kubernetes
|
||||
- helm
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-02
|
||||
title: Шаблонизатор Helm
|
||||
---
|
||||
|
||||
# Шаблонизатор Helm
|
||||
|
||||
**Helm** — менеджер пакетов и шаблонизатор для развёртывания приложений в [[Kubernetes]].
|
||||
|
||||
Helm помогает описывать, устанавливать, обновлять и удалять приложения через готовые или собственные Helm charts.
|
||||
|
||||
## Зачем нужен Helm
|
||||
|
||||
Helm позволяет:
|
||||
|
||||
- искать готовые charts;
|
||||
- устанавливать приложения в Kubernetes;
|
||||
- обновлять релизы;
|
||||
- удалять приложения;
|
||||
- переиспользовать шаблоны манифестов;
|
||||
- параметризовать установку через values.
|
||||
|
||||
## Helm chart
|
||||
|
||||
**Helm chart** — пакет с шаблонами Kubernetes-манифестов, значениями по умолчанию и метаданными приложения.
|
||||
|
||||
Chart можно:
|
||||
|
||||
- найти в публичном chart-репозитории;
|
||||
- создать самостоятельно под своё приложение.
|
||||
|
||||
## Базовый workflow
|
||||
|
||||
Добавить chart-репозиторий:
|
||||
|
||||
```sh
|
||||
helm repo add bitnami https://charts.bitnami.com/bitnami
|
||||
```
|
||||
|
||||
Обновить индекс репозиториев:
|
||||
|
||||
```sh
|
||||
helm repo update
|
||||
```
|
||||
|
||||
Найти chart:
|
||||
|
||||
```sh
|
||||
helm search repo bitnami
|
||||
```
|
||||
|
||||
Установить приложение:
|
||||
|
||||
```sh
|
||||
helm install my-mysql bitnami/mysql
|
||||
```
|
||||
|
||||
Посмотреть доступные параметры:
|
||||
|
||||
```sh
|
||||
helm show values istio/base
|
||||
```
|
||||
|
||||
Установить или обновить значения через `--set`:
|
||||
|
||||
```sh
|
||||
helm install istiod istio/istiod --set requests.cpu=300m
|
||||
```
|
||||
|
||||
Посмотреть установленные релизы:
|
||||
|
||||
```sh
|
||||
helm list
|
||||
```
|
||||
|
||||
Обновить релиз:
|
||||
|
||||
```sh
|
||||
helm upgrade istiod istio/istiod --set requests.cpu=600m
|
||||
```
|
||||
|
||||
## Связанные заметки
|
||||
|
||||
- [[Kubernetes]]
|
||||
- [[DevOps - основы]]
|
||||
@@ -0,0 +1,72 @@
|
||||
---
|
||||
status: seed
|
||||
type: guide
|
||||
tags:
|
||||
- devops
|
||||
- git
|
||||
- cli
|
||||
created: 2025-12-17
|
||||
updated: 2026-05-02
|
||||
title: Основные команды git
|
||||
---
|
||||
|
||||
# Основные команды git
|
||||
|
||||
Эта заметка — краткий справочник по базовым командам [[Git]].
|
||||
|
||||
## Создание и получение репозитория
|
||||
|
||||
- `git init` — создать новый Git-репозиторий в текущем проекте.
|
||||
- `git clone` — создать локальную копию удалённого репозитория.
|
||||
|
||||
## Работа с ветками
|
||||
|
||||
- `git branch` — показать, создать или удалить ветки.
|
||||
- `git checkout` — переключиться на ветку, файл или коммит.
|
||||
- `git merge` — слить одну ветку в другую.
|
||||
- `git rebase` — перебазировать ветку поверх другой ветки.
|
||||
|
||||
## Работа с изменениями
|
||||
|
||||
- `git status` — показать состояние рабочего каталога.
|
||||
- `git add` — добавить изменения в индекс.
|
||||
- `git commit` — зафиксировать проиндексированные изменения.
|
||||
- `git restore` — откатить изменения или убрать их из индекса.
|
||||
- `git revert` — создать новый коммит, отменяющий выбранный старый коммит без переписывания истории.
|
||||
|
||||
## Работа с удалённым репозиторием
|
||||
|
||||
- `git push` — отправить локальные коммиты в удалённый репозиторий.
|
||||
- `git pull` — получить изменения из удалённого репозитория и сразу объединить их с локальной веткой.
|
||||
|
||||
Платформы вроде [[Gitlab]] используют эти операции как основу для командной разработки, merge request и CI/CD.
|
||||
|
||||
## Merge и rebase
|
||||
|
||||
`git merge` и `git rebase` решают одну задачу: переносят изменения из одной ветки в другую. Разница в том, как они меняют историю.
|
||||
|
||||
### Merge
|
||||
|
||||
`git merge` создаёт слияние веток без переписывания уже существующих коммитов. Это безопасный вариант для публичных веток.
|
||||
|
||||
|
||||
|
||||
### Rebase
|
||||
|
||||
`git rebase` переносит коммиты текущей ветки поверх другой ветки и помогает получить более линейную историю.
|
||||
|
||||
|
||||
|
||||
> [!important] Золотое правило rebase
|
||||
> Не выполнять `git rebase` над публичной веткой, если её уже используют другие разработчики.
|
||||
|
||||
## Когда выбирать merge или rebase
|
||||
|
||||
- Если нужно сохранить полную историю и не переписывать публичные коммиты — использовать `git merge`.
|
||||
- Если нужна чистая линейная история в локальной или личной ветке — использовать `git rebase`.
|
||||
|
||||
## Связанные заметки
|
||||
|
||||
- [[Git]]
|
||||
- [[Gitlab]]
|
||||
- [[DevOps - основы]]
|
||||
Reference in New Issue
Block a user