MaxRokatansky Apr 2 2018 at 12:40

Золотое правило git rebase

4 min

29K

OTUS corporate blogProgramming*Git*

Translation

+18

Comments 18

Virviil Apr 2 2018 at 17:26

А что будет, если Анна выполнит git rebase origin/feature в локальную feature ветку?

humbug Apr 2 2018 at 18:36

Угу. Про git pull --rebase не слышали, про git rebase -mp не слышали. Можно делать ребейз публичной ветки, но это исключительная ситуация, к которой надо соответствующе подготовиться.

andy_shev Apr 2 2018 at 23:09

Нет, не надо делать git rebase для опубликованной (published) (не публичной (public), заметьте!) ветки.

humbug Apr 3 2018 at 04:20

Меня данный пост не переубедил. Почему нет? По хорошему, с веткой должен работать только один человек. Если разработчиков больше одного, то необходимо согласовать ребейз со всеми и переписать историю. Это бывает, особенно при длительной работе над какой-нибудь фичей.

andy_shev Apr 3 2018 at 11:18

Я специально привёл терминологию. Вы путаете опубликованные ветки с публичными. Никто не запрещает делать git rebase в публичных ветках (тем более в приватных), а вот в опубликованных этого делать нельзя. Или ваши пользователи мазохисты до мозга костей, или вы что-то недопонимаете…

nick7ikin Apr 3 2018 at 13:51

Более обобщенно правило выглядит так: «не изменяйте опубликованную историю». А золотое правило git rebase — не использовать его )). Оставлю для подтверждения пару ссылок: Чем опасен rebase, или как получилось, что 2*3=5, Почему нужно перестать использовать Git rebase

-2

nick7ikin Apr 5 2018 at 15:28

комрады, если ставите минус, пожалуйста, подкрепляйте своё мнение аргументами в камментах.

mayorovp Apr 5 2018 at 19:16

В тех постах, на которые вы ссылаетесь, тоже есть комментарии…

andy_shev Jul 27 2018 at 22:35

Ну вы же чушь пишите про git rebase ... Это совершенно мощный инструмент разработчика. Как один из его неявных вариантов git pull --rebase ... Надо, как и везде, понимать что к чему и как использовать инструменты. Например, разработка ядра не могла бы вестись человеческим образом (да и любого проекта, где оперируют сериями патчей) без git rebase ...

UFO just landed and posted this here

dravor Apr 3 2018 at 13:51

В тексте, расписывающим азбучные правила, так и не написано зачем вообще кому-то может понадобиться делать rebase.

snp Apr 3 2018 at 17:54

По-моему, текст можно было укоротить до одного позитивного кейса: gut pull --rebase; больше я не могу представить ни одного случая, зачем rebase может понадобиться.

А так-то да, git даёт кучу возможностей и инструментов для отстреливания себе ног.

-1

WALKER898 Apr 6 2018 at 01:59

почитайте про rebase -i

-1

michael_v89 Apr 6 2018 at 06:27

Никогда, НИКОГДА, НИКОГДА не делайте rebase общей ветки.

Да можно так делать, просто надо договариваться.

Скажем, Алиса склонировала себе ветку Боба для код-ревью или для проверки работы, а потом Боб сделал rebase и изменил 3 последних коммита. Боб сообщает ей об этом. Если Алиса сделает git pull то локально у нее будет merge commit. Ей надо сделать git reset --hard HEAD~3 && git pull, тогда новые коммиты применятся через fast forward.

В общем-то, можно даже не договариваться. Алиса получает merge commit, [говорит "Ай-яй-яй, Боб"], делает git reset --hard HEAD~1 для отмены мерж коммита, находит последний общий коммит в историях и откатывается на него, потом делает git pull.

Если Алиса тоже делала коммиты в эту ветку, то принцип такой же, просто надо после pull применить эти коммиты.

mayorovp Apr 6 2018 at 08:56

Да не надо ничего искать, достаточно git checkout origin/bob -B bob...

michael_v89 Apr 6 2018 at 13:24

Хм, действительно) Помню, что зачем-то так делал. Может какая-то другая ситуация была, а может правда про checkout не подумал.

antonkrechetov Apr 9 2018 at 12:12

Как человек, немного знакомый с гитом, хочу добавить несколько замечаний:

Это имеет два важных последствия:

Переприменяя коммиты, git создает новые.

Вообще говоря, два важных последствия не имеют прямого отношения к rebase-у. Уникальным идентификатором коммита в гите является хэш, который вычисляется, в частности и по хэшу родительских коммитов. Поэтому естественно, что при ответвлении от другого родителя идентификатор поменяется.

Git rebase переприменяет коммиты, не уничтожая старые.

Все команды гита, изменяющие состояние репозитория, обычно не уничтожают неиспользуемые объекты. Из-за этого в гите довольно сложно необратимо повредить репозиторий) Для очистки объектов существуют специальные команды типа git gc.

Я думаю, что куда больше проблем, чем при нарушении «золотого правила», возникает вот здесь:

Естественно, Анна пулит.

Если вы хоть немного знакомы с гитом, никогда не делайте git pull. git pull — это команда, придуманная, чтобы немного облегчить работу с гитом новичкам. Правильная последовательность действий такая:

git fetch — чтобы забрать все изменения из удаленного репозитория.
изучение текущего состояния удаленной ветки (сравнение коммитов со своими, просмотр изменений и т.п.).
В зависимости от того, что там оказалось, вы можете в своей локальной копии ветки захотеть сделать либо fast forward либо rebase либо merge либо reset либо пойти к коллегам разбираться, почему в ветке фигня. А возможно, что придется переписать часть своих изменений.

andy_shev Jul 27 2018 at 22:43

… или git remote update -p. Тем не менее git pull --rebase ... очень полезен.