# Git: Интерактивный ребейз и как дропнуть или объединить коммиты
:exclamation: **Важно:** кейс может быть частым, если вы не договорились с разработчиками о том, что форспушить в общую ветку нельзя.
---
**В реальности:**
Вы открываете свой PR в GitHub, а там вперемешку с вашими коммитами - коммиты разработчика. Обычно они там появляются после того, как разработчик форспушит что-то в ветку, от которыой вы ответвились.
**Что делать:**
Левые коммиты нужно либо дропнуть либо обновить ветку, чтобы вашим ревьюверам не мешал код фронта/бэка (ну и не только).
Для дропа или объединения коммитов делаем интерактивный ребейз, т.е. **`git rebase -i`**:
**1. Переключаемся на свою ветку (с последними изменениями):**
```bash
git checkout {task-branch-name}
```
**2. Делаем rebase -i на то количество коммитов, которые нужно изменить.
Считаем количество коммитов от последнего и пишем это число в консольную команду:**
```bash
git rebase -i HEAD~число
```
**3. Открывается файл в текстовом редакторе со списком коммитов, мы должны отредактировать этот файл:**
**pick** - прописано по-дефолту перед каждым коммитом.
- Находим в списке коммиты разработчика и меняем **pick** на **drop**;
- Редактируем свои коммиты (если нужно);
- После этого сохраняем файл (ctrl+s) и закрываем редактор.
📃Список команд в редакторе прилагается:

если нет конфликтов, то процесс ребейза должен завершиться.
Если есть конфликты - резолвим их.
❗На этом этапе часто ребейз выходит из под контроля.
Поэтому, после ребейза (до пуша в удалённую ветку) нужно сбилдить проект локально и проверить изменения в коде.
Если всё плохо, то откатываемся:
```bash
git reset --hard origin/{task-branch-name}
```
и делаем ребейз заново.
После удачного ребейза можете проверить коммиты (для уверенности) через
```bash
git log
```
**4. Делаем форспуш в свою удалённую ветку:**
```bash
git push origin {task-branch-name} --force-with-lease
```
**Note:** Git-опция `--force-with-lease` безопаснее дефолтного `--force` т.к. действует гораздо аккуратнее: она проверяет, чтобы ваша локальная копия ref’а была самой свежей, прежде чем накатить её. Т.е. вы не затрёте своим форспушем свежие коммиты коллеги, если работаете в одной общей ветке.
###### tags: `Git` `rebase` `rebase -i`