Как стать автором
Обновить

Комментарии 18

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

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

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

Я специально привёл терминологию. Вы путаете опубликованные ветки с публичными. Никто не запрещает делать git rebase в публичных ветках (тем более в приватных), а вот в опубликованных этого делать нельзя. Или ваши пользователи мазохисты до мозга костей, или вы что-то недопонимаете…
Более обобщенно правило выглядит так: «не изменяйте опубликованную историю». А золотое правило git rebase — не использовать его )). Оставлю для подтверждения пару ссылок: Чем опасен rebase, или как получилось, что 2*3=5, Почему нужно перестать использовать Git rebase

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

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

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


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

почитайте про rebase -i
Никогда, НИКОГДА, НИКОГДА не делайте 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 применить эти коммиты.

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

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

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

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

Я думаю, что куда больше проблем, чем при нарушении «золотого правила», возникает вот здесь:
Естественно, Анна пулит.
Если вы хоть немного знакомы с гитом, никогда не делайте git pull. git pull — это команда, придуманная, чтобы немного облегчить работу с гитом новичкам. Правильная последовательность действий такая:
  • git fetch — чтобы забрать все изменения из удаленного репозитория.
  • изучение текущего состояния удаленной ветки (сравнение коммитов со своими, просмотр изменений и т.п.).
  • В зависимости от того, что там оказалось, вы можете в своей локальной копии ветки захотеть сделать либо fast forward либо rebase либо merge либо reset либо пойти к коллегам разбираться, почему в ветке фигня. А возможно, что придется переписать часть своих изменений.
… или git remote update -p. Тем не менее git pull --rebase ... очень полезен.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.