# Git: Работа с ветками

**master / main / default / trunk** - стандартные названия основных ветвей. Стабильные ветки, из которых обычно выпускают релизы.

**dev / development** - основная ветка разработки, туда вносятся текущие изменения, не считается стабильной. Если изменений вносится немного (поправить пару строчек / заменить конфиг / обновить библиотеку с сохранением совместимости) и эти изменения безопасны допустимо добавление коммитов непосредственно в dev-ветвь. Во всех остальных случаях стоит использовать feature-branch.

**feature-branch / ticket-branch** - ветка, унаследованная от develop в которую вносятся точечные изменения, например добавление фичи, исправление бага. Тикет бранчи именуются с номером соответствующего тикета/задачи. Так можно по названию ветки найти задачу и понять цель изменений. И наоборот: по тикету найти ветку. В этой ветке может существовать частично нерабочее состояние репозитория.

### Полный классический Git flow

![Screenshot 2024-10-05 211241.png](https://notes.annndruha.space/attachments/4)

### Более простая схема для роли developer

![Screenshot 2024-10-05 211246.png](https://notes.annndruha.space/attachments/2)

### Процесс работы в feature-branch

![Screenshot 2024-10-05 211252.png](https://notes.annndruha.space/attachments/3)

## Безопасное удаление ветвей

Если неслитые ветки удалять через интерфейс гитлаба/гитхаба, то все изменения в этих ветвях навсегда будут утеряны. Чтобы такого не происходило, можно перед удалением ветки навесить на неё тег: (например тег archive/назв.ветки)

```bash
git clone <url репозитория>    (если нет локальной копии)
cd <репозиторий>

git checkout <имя ветки для закрытия>
git tag archive/<имя ветки для закрытия> <имя ветки для закрытия>
git checkout <любая другая ветка>
git branch -D <имя ветки для закрытия>
git branch -d -r origin/<имя ветки для закрытия>
git push --tags
git push -d origin <имя ветки для закрытия>
```

#### Как работает MR
На самом деле при merge/MR происходит чуть более сложная логика чем просто наложение diff разных коммитов последовательно друг на друга. [Подробнее можно почитать здесь](https://docs.gitlab.com/ee/user/project/merge_requests/methods/).

В настройках репозитория можно выбрать метод для merge:

![Screenshot 2024-10-05 211819.png](https://notes.annndruha.space/attachments/5)