Комментарии 26
rebase, особенно интерактивный, — это способ переписать историю: перенести коммиты, убрать, добавить, переименовать. С историей можно сделать всё что угодно.
Зачем переписывать историю — большой вопрос.
Кто-то считает, что история коммитов должна оставаться неизменной, потому что она показывает как развивался проект.
Кто-то (я, например) считает, что в публичный репозиторий должен попадать "причёсанный" код, где каждый коммит приносит какаю-то ценность проекту.
Я делаю по несколько десятков коммитов ежедневно просто, чтобы не потерять прогресс. Большая часть из них — это черновая работа, проверка версий и гипотез. Я считаю, что подобные вещи не приносят ценности проекту, поэтому из множества черновых коммитов в итоге я рибейсом собираю 1-2 осмысленных чистовых. По ним можно адекватно проследить историю развития проекта, а самое главное — их можно легко откатить.
Публичную историю лучше держать неизменной (точнее, не так, НУЖНО держать неизменной. Ваш тезис про rebase в пошаренный код ).
Личной историей можно управлять по своему разумению.
Не все привыкли раскладывать код по полочкам, не всегда это возможно.
Например, пишешь новую фичу, решил ради неё добавить функций в глобальную либу проекта. Сперва ради скорости вкоммитал в один коммит, а позже решил разделить изменения в либу от фичи.
Или — в основной ветке решили переименовать глобальную сущность из foo в bar.
Может в отдельном коммите, может в "комбайне" других изменений (вы на это не влияете), но суть в том, что вы у в своей фиче тоже много где заюзали foo.
В первом случае — rebase -i, встаём на нужный коммит, делаем reset HEAD~ и делаем нужное количество коммитов. В одном изменения в глобальную либу, в другом — новые строчки от фичи и т.д. Делаем снова rebase -i, и коммиты с изменениями в глобал группируем и сливаем в один, если нужно. Остальные — по своему усмотрению. По итогу мухи и котлеты отделены, можно работать дальше!
Во втором случае — делаем то же переименование поверх своей ветки (тем же способом, что было сделано в основной. Например, через. IDE). Коммитаем, ребейзим. В результате переписывания получаем коммит с переименованием ровно тех моментов, что вы добавили (а те, что приплыли из основной ветки автоматически отбросятся, как совпадающие).
Ну и третий момент — то же, что и первый, только более глобально. Накодили три сотни коммитов, а в ветке хочется оставить пару десятков. Rebase -i и вперёд.
Итоговую ветку можно заребейзить или смержить, это уже неважно. Главное, историю предварительно очистили от мусора.
Изредка даже форс пуш бывает.
Инструмент, как обычно, не виноват.
Один из примеров полезности rebase:
Есть очень-очень крупный проект (master) и есть свой личный форк (fork) проекта с личными изменениями, которые, по каким-то причинам, не могут быть приняты (либо не хочется отправлять) в апстрим. Проект большой (десятки-сотни тысяч коммитов), личные изменения — максимум 10-20 коммитов.
Пришло время подтянуть свежие обновления из крупного проекта. Есть два варианта:
1) можно замержить master → fork
2) можно сделать rebase
В случае «1» наши фиксы со временем перемешиваются с коммитами из апстрима и через пару лет уже будет трудно разобраться, что происходит.
В случае «2» у нас всегда в ветке fork сверху те 10-20 коммитов с нашими фиксами и ситуация всегда ясна, конфликты проще разрешить при значительных изменениях в апстриме.
Для облегчения ситуации можно при каждом обновлении из апстрима создавать новую ветку fork-YYYYMMDD, чтобы после rebase хэши коммитов не менялись.
Для облегчения ситуации можно при каждом обновлении из апстрима создавать новую ветку fork-YYYYMMDD, чтобы после rebase хэши коммитов не менялись.После rebase хэши, всё-равно, поменяются, потому что объект коммита содержит в себе указатель на предка, и если тот меняется (а при rebase это всегда происходит), то и хэш всего коммита меняется. И последующих, аналогично.
Я имел в виду, чтобы старую ветку не трогать (чтобы в ней хэши коммитов не менялись), а создать новую и очередной rebase уже там делать. Пример:
1) есть наш форк 2-недельной давности (our-20200414) и новые изменения в master, поверх которых надо наши изменения положить
* 8ce46bb (HEAD -> master) 5
* cda3070 4
| * 95f2d51 (our-20200414) 5'
| * 07a2aee 4'
|/
* d8695a4 3
* 82dc170 2
* 59a32e9 12) делаем rebase
git checkout -b our-20200428 master
git rebase --onto our-20200428 d8695a4 95f2d51
git branch -f our-202004283) получили:
* e2e5630 (HEAD, our-20200428) 5'
* f1ed7e7 4'
* 8ce46bb (master) 5
* cda3070 4
| * 95f2d51 (our-20200414) 5'
| * 07a2aee 4'
|/
* d8695a4 3
* 82dc170 2
* 59a32e9 1
* 87aa0fa “root”
Я в гите относительно недавно. А что за мерж, которые не создает коммитов? Что вы имели ввиду?
error: failed to push some refs to 'https://github.com/miranda-ng/miranda-ng'
hint: Updates were rejected because the remote contains work that you do not have locally. This is usually caused by another repository pushing to the same ref. You may want to first integrate the remote changes (e.g., 'git pull ...') before pushing again. See the 'Note about fast-forwards' in 'git push --help' for details.
Если я не сделаю «rebase after merge», то мой коммит (когда он таки улетит на сервер) будет выглядеть как две записи в истории:
Merge branch 'master' of github.com/miranda-ng/miranda-ng
Fix spelling
Первая из двух записей — информационный мусор, который никакой пользы остальным участникам не несёт. Он прилетит всем, кто подписан, например, по RSS на историю коммитов (некоторые пользователи, совершенно точно, подписаны и следят за ходом разработки). Зачем им это?
P.S. Возможно, я использую git как-то неправильно и ужасно, но я не программист, сложные и большие коммиты с разработкой новых фич не делаю, все мои правки сводятся к таким вот тривиальным исправлениям мелких и очевидных ошибок.
и ни одного слова зачем он вообще может быть нужен. Я например не знаю.
Поправить опечатку в сделанном ранее коммите, внести доработки, которые сразу не учел. То есть всё то, для чего нужен amend, только для предыдущих коммитов.
Помимо этого объединить промежуточные шаги в законченный коммит. Это работает немного наоборот. Когда вы не исправляете коммиты, вы держите все изменения незакоммиченными, и коммитите когда уверены что все сделано. Это создает дополнительную умственную нагрузку, особенно если надо проверить несколько вариантов реализации (и выбрать тот, который не последний) — ага, тут я поменял, надо еще в том файле поменять, в этом вот это убрать, а вот это не трогать, в этом было мало изменений, можно Ctrl+Z нажать несколько раз, все поменял, проверил, можно коммитить. С исправлением коммитов можно любой шаг коммитить, и при проверке очередной версии не держать все в голове, а просто вносить изменения, если что-то упусил, будет еще один коммит. Потом это все объединяется в 1 или несколько нормальных коммитов. "Наоборот" тут в том смысле, что не rebase дает что-то конкретное, а без rebase сложнее, но пока не попробуешь делать с rebase, это неочевидно.
Можно коммитить все подряд и не объединять, но тогда в истории будет сложнее разбираться, или вносить какие-то новые изменения, которые должны быть аналогичны старым.
Руководство по Git. Часть №2: золотое правило и другие основы rebase