Что происходит с коммитами ветки feature при выполнении rebase на ветку develop

Что проверяют

Знаете ли вы механику: что именно переносится, в каком порядке и почему после переноса ветка расходится со своей же копией на сервере. Вопрос задают и тем, кто пишет на Go, потому что это общая командная гигиена, а не тема про язык.

Как отвечать

• git rebase develop из ветки feature находит общего предка, откладывает ваши коммиты и накладывает их по одному на вершину develop в прежнем порядке. Коммиты develop при этом не копируются, переезжает только ваша часть.
• Каждый коммит пересоздаётся: новый родитель означает новый хеш. Ветка перестаёт быть продолжением своей удалённой копии, поэтому обычный push отклоняется и нужен --force-with-lease.
• Коммиты, изменения которых уже есть в develop, например забранные отдельным переносом, Git выбрасывает как пустые. Это нормальный исход, а не потеря работы.
• Конфликты разбираются на каждом коммите отдельно: остановка, правка, git add, git rebase --continue, при необходимости --skip или --abort. Слияние тут отличается принципиально, там конфликт решается один раз на итоговом состоянии.
• Для проекта на Go стоит добавить практическую деталь: go.sum и сгенерированный код конфликтуют на каждом шаге, их проще перегенерировать после переноса, чем сводить руками. А промежуточные коммиты после rebase никогда не собирались, поэтому при аккуратной истории прогоняют git rebase --exec "go build ./..." develop.

Где спотыкаются

Описывают rebase как «подтягивание develop в feature». Изменения develop действительно оказываются в истории ниже ваших коммитов, но переписываются при этом ваши, а не чужие, и форсированной заливки требует именно ваша ветка.

Второе: после разрешения конфликта делают git commit вместо git rebase --continue. Появляется лишний коммит посреди переноса, процесс остаётся незавершённым, и дальше человек обычно делает слияние поверх, получая в истории и перенос, и merge сразу.

Третье: ребейзят ветку, на которую уже открыт запрос на слияние и которую кто-то успел забрать себе. Коллеге придётся вручную выбираться из расхождения, а комментарии ревью останутся привязанными к исчезнувшим коммитам и потеряют контекст. О переписывании общей ветки договариваются заранее.