Комментарии 18
А что будет, если Анна выполнит git rebase origin/feature в локальную feature ветку?
Угу. Про git pull --rebase
не слышали, про git rebase -mp
не слышали. Можно делать ребейз публичной ветки, но это исключительная ситуация, к которой надо соответствующе подготовиться.
git rebase
для опубликованной (published) (не публичной (public), заметьте!) ветки.Меня данный пост не переубедил. Почему нет? По хорошему, с веткой должен работать только один человек. Если разработчиков больше одного, то необходимо согласовать ребейз со всеми и переписать историю. Это бывает, особенно при длительной работе над какой-нибудь фичей.
комрады, если ставите минус, пожалуйста, подкрепляйте своё мнение аргументами в камментах.
git rebase ...
Это совершенно мощный инструмент разработчика. Как один из его неявных вариантов git pull --rebase ...
Надо, как и везде, понимать что к чему и как использовать инструменты. Например, разработка ядра не могла бы вестись человеческим образом (да и любого проекта, где оперируют сериями патчей) без git rebase ...
Никогда, НИКОГДА, НИКОГДА не делайте 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
применить эти коммиты.
Это имеет два важных последствия:Вообще говоря, два важных последствия не имеют прямого отношения к rebase-у. Уникальным идентификатором коммита в гите является хэш, который вычисляется, в частности и по хэшу родительских коммитов. Поэтому естественно, что при ответвлении от другого родителя идентификатор поменяется.
Переприменяя коммиты, git создает новые.
Git rebase переприменяет коммиты, не уничтожая старые.Все команды гита, изменяющие состояние репозитория, обычно не уничтожают неиспользуемые объекты. Из-за этого в гите довольно сложно необратимо повредить репозиторий) Для очистки объектов существуют специальные команды типа git gc.
Я думаю, что куда больше проблем, чем при нарушении «золотого правила», возникает вот здесь:
Естественно, Анна пулит.Если вы хоть немного знакомы с гитом, никогда не делайте git pull. git pull — это команда, придуманная, чтобы немного облегчить работу с гитом новичкам. Правильная последовательность действий такая:
- git fetch — чтобы забрать все изменения из удаленного репозитория.
- изучение текущего состояния удаленной ветки (сравнение коммитов со своими, просмотр изменений и т.п.).
- В зависимости от того, что там оказалось, вы можете в своей локальной копии ветки захотеть сделать либо fast forward либо rebase либо merge либо reset либо пойти к коллегам разбираться, почему в ветке фигня. А возможно, что придется переписать часть своих изменений.
Золотое правило git rebase