🟢 В каком случае использовать merge и rebase

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

Стоит озвучить несколько правил, которые помогут сохранить лицо и отношения с командой:

• Никогда не пушить коммиты в чужие рабочие ветки. Создайте свою ветку и ведите работу в ней. Если работаете над этими изменениями в одиночестве, то даже пушить эту ветку сразу не обязательно (но лучше этим не пренебрегать, конечно).

• Используйте rebase только для веток, которыми управляете лично. Rebase переписывает историю коммитов и меняет их хэши. Если кто-то уже работает с этой веткой, после rebase ему придется разбираться с конфликтами и синхронизацией истории. Во все остальные ветки - только merge, чтобы избежать перелома лица или рук от заботливых коллег.

git merge#

Наименее деструктивный способ влить изменения из одной ветки в другую. Не изменяет и не стирает историю коммитов. История полностью сохраняется, но со временем может стать запутанной. Merge всегда двигается вперед во времени, то есть мы берем прошлые изменения и добавляем к ним новые.

Мы отпочковались от master и пишем документацию в своей ветке feature. Чтобы перенести новые коммиты, появившиеся в master, используем merge:

1. Для этого мы должны быть на своей ветке - git checkout feature
2. Мержим коммиты из master в нашу фича-ветку - git merge master
3. Появится новый merge commit в нашей feature ветке. Это новый коммит слияния изменений, то есть git добавит новый коммит с новым хэшем в вашу фича-ветку со всеми изменениями, которые произошли в master после того, как вы отпочковали от него свою ветку.

    master

    A---B---C

            \
    feature   D---E

git rebase#

Мы "ребейсим" то, откуда начинается наша ветка. Это влияет на историю коммитов. Делает историю коммитов более линейной.

interactive rebase#

В каком случае я бы использовала git merge#

В каком случае я бы использовала git rebase#