rebase, flow

rebase — альтернатива merge: переносит твои коммиты так, будто ты начал ветку только что, поверх свежего main. Результат — чистая, линейная история, без “развилок” от merge-коммитов.

git checkout feature/login
git rebase main   # "перенести" мои коммиты поверх свежего main

<text x="320" y="14" text-anchor="middle" font-size="11" fill="currentColor" opacity="0.6">rebase — линия прямая</text>
<line x1="240" y1="60" x2="400" y2="60" stroke="currentColor" stroke-opacity="0.5" stroke-width="2"/>
<circle cx="280" cy="60" r="6" fill="currentColor" fill-opacity="0.6"/><circle cx="320" cy="60" r="6" fill="#16a34a"/><circle cx="360" cy="60" r="6" fill="#16a34a"/>

Git flow — одна из устоявшихся моделей организации веток в команде: main (всегда рабочая прод-версия), develop (текущая разработка), feature/* (отдельные фичи, ответвляются от develop), release/*, hotfix/* (срочные правки прямо в main).

Копнуть глубже

Главное правило rebase: никогда не делай его на ветке, которую уже видели другие (запушили и кто-то из неё что-то взял). rebase переписывает историю — создаёт новые коммиты вместо старых, и если кто-то уже работает со старыми коммитами, начинается путаница и конфликты у всех сразу.

Когда выбирать что:

merge — для общих веток (например, фичу в main), безопасен, сохраняет реальную историю как было.
rebase — для своей личной ветки до того, как её увидели другие — чтобы синхронизироваться со свежим main, не плодя лишних merge-коммитов.

В реальных командах часто принят простой Git flow без формальных develop/release веток: только main + короткоживущие feature/* через Pull Request — это называется trunk-based development и сейчас популярнее классического Git flow.

🎤 Закрыл тему, если можешь объяснить:

• чем `rebase` отличается от `merge` по результату в истории;
• золотое правило безопасности rebase и зачем нужны ветки flow (если дошёл до 2-го слоя).