Git: помогите освоить rebase

PR это не публичная история, его можно и нужно редактировать

Похоже, мы с тобой смотрим в разные толковые словари и по-разному понимаем слово «публичный».

чтобы в публичной истории не было мусора

История это не мусор. Это раз. Но для такого случая у Гитхаба можно делать squash merge при слиянии ПР. Хоть, я и против такого, но очень часто его встречаю на работе.

В github, в отличие от, скажем, gerrit, pr нельзя обновить без force --push

Ты имел ввиду, в Gerrit нельзя без --force? Потому как в Github это делается легко.
У Гугла другие масштабы, там монорепа с миллионами коммитов в секунду. Возможно, этим продиктовано.

https://yarchive.net/comp/linux/git_rebase.html

In other words, you really shouldn't rebase stuff that has been exposed
anywhere outside of your own private tree. But *within* your own private
tree, and within the commits that have never seen the light of day,
rebasing is fine.

Линус тоже так считает.

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

Так они упоротые, если разрешают только 1 коммит в ПР.

Да я сам виноват, надо было протестировать на тестовых репозиториях

Теоретически, да. На практике, в команде, очень маловероятно, что кто-то стянет твой ПР до того, как он проревьюен и смержен.

На моей регулярно.
0. Люди стягивают код с ПР чтобы просматривать его локально, в ИДЕ а не только в ГХ морде.
1. Кто-то не доделал работу и заболел, другой добавляет туда коммит и вливают ПР не дожидаясь автора ПР.
2. Вот прямо сейчас, коллега делает свою работу на основе ветки моего (ещё не влитого) ПР.

С rebase история будет выглядеть красивее и понятнее.

Возможно, красивей. Допустим. Но история не про красоту а про историю. Чтобы она была красивой достаточно не оглавлять коммиты «some fixes». Я уже писал выше, какие проблемы привносит эта красивая история.

Так конфликты в любом случае будут в командной разработке. Хоть merge используй, хоть rebase - от этого не зависит.

Чтобы не было конфликтов, пытаются придумать VCS на других основах: darcs, pijul. Не знаю, как там у них выходит.

С merge конфликтов меньше.

С merge конфликтов меньше.

в разы меньше. но больше всего меня в ребейзе –force напрягает. это наводит на мысль, что при нем воркфлоу не такой, какой задумывался с гитом. подобные аргументы у любого софта предназначены для насильного изменения состояния минуя штатный цикл переходов

это просто сахар для клиента

Но он же не делает push –force. Просто история в trunk-ветке становится более атомарной.

Но он же не делает push –force. Просто история в trunk-ветке становится более атомарной.

вы реально не знаете что на самом делает git merge --squash и как то же самое сделать другими командами? а git commit --amend - это тоже из разряда черной магии или как?

rebase - козёл, хотя, наверное, со мной не согласятся

Так они упоротые, если разрешают только 1 коммит в ПР.

там у ТС изначально идея про то, что вот в этот void linux залить рецепты по сборке какого-то пакета, откуда там должно взяться более одного коммита-то? В одном коммите нужно написать эссе почему я решил добавить новый пакет, а в другом это самое добавление осуществить? Такая тема канает разве что в разработке и то не всегда: сначала добавляем провальные тесты - все видят, что они красные, потом с гордостью их чиним.

Мейнтейнер апстрима указал в каком виде он хочет видеть ПР - извольте соблюдать правила.

вы реально не знаете что на самом делает git merge –squash и как то же самое сделать другими командами?

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

Встречал в серьезных банковских приложениях с двухнедельными, месячными циклами релизов. Где задача берется в работу, делается два месяца и надо все плотно протестировать перед релизом, думаю во всяких десктопных приложениях, типа игр тоже ок.

В современной быстрой веб разработке оно неудобно, да.

Думаю, что даже в «серьёзных» приложениях (в т.ч. и больших веб-приложениях) в большинстве случаев это упрощённый git flow: есть некоторая trunk-ветка (master, develop), в которую вливаются фичи и багфиксы, и от которой периодически отделяются релизные ветки. То есть просто нет всегда стабильной ветки master.

Давай слово «серьезный», особенно в применении к банковским приложениям уберем, как эмоции и заведомое манипулирование. «Всё плотно протестировать» - это вопрос к организации тестов. Если контора отсталая и там только ручные тесты, то им ничего не поможет. Если тесты делает робот, то гонять можно много раз в день.

Как откладывание мержа в мастер и увеличение импакта помогает работе? Ведь средний банковский разработчик - это не то чтобы очень вовлеченный человек, ему бы мастер в голове удержать, как он может 10 веток удерживать?

Как откладывание мержа в мастер и увеличение импакта помогает работе? Ведь средний банковский разработчик - это не то чтобы очень вовлеченный человек, ему бы мастер в голове удержать, как он может 10 веток удерживать?

Там не так на самом деле: разработчик сделал свою фичу, её протестировали и влили в транк, а перед релизом всё ещё раз тестируется на отдельных стендах со всеми подготовленными релизными версиями бекендных компонентов.

Зачем убирать слово, я тебе свой пример привожу, серьезные это когда у тебя миллиарды денег считаются и ошибка на копейку за несколько минут превращается в потерю миллионов.

Ребейз нинужно, есть мерж.

Я тебе больше скажу про эти «серьезные» конторы, где я работал был еще аудит кода, комиты попавшие в релиз скринились, а распечатки передавались на проверку аудиторам

откуда там должно взяться более одного коммита-то?

Да хоть новая версия пакета вышла пока ПР висел и теперь ее нужно в этом же ПР обновить.

Такая тема канает разве что в разработке и то не всегда: сначала добавляем провальные тесты - все видят, что они красные, потом с гордостью их чиним.

А тут не понял. При разработке ПРы чуть менее чем всегда дорабатываются в процессе code review.

При разработке ПРы чуть менее чем всегда дорабатываются в процессе code review.

ну дорабатываются и пусть дорабатываются, я же при этом не ожидаю появления коммитов с текстом «Исправление замечаний», а ожидаю, чтобы замечание было исправлено в конкретном коммите, который вызвал это замечание.

Надо всегда делать rebase. Иначе история проекта превращается в нечитаемую лапшу, в которой никто никогда не сможет разобраться. История должна быть линейная. Либо просто добавлять все pull request-ы через fast-forward или squash. Либо делать один merge коммит в главную ветку, а рядом подвязывать оригинальную историю коммитов параллельной веткой.

--force использовать нежелательно для main ветки. Для других веток - можно. Над веткой работает один разработчик и делает с веткой что хочет.

а ожидаю, чтобы замечание было исправлено в конкретном коммите, который вызвал это замечание.

Я выше писал, почему это плохо.

История должна отображать то, что происходило. Если задачу пилили в отдельной ветке месяц и по ходу дела менялось и ее понимание и требования то это должно отображаться в истории. А линейная ничего из этого не отображает.

Теоретически, наверное, да. На практике ещё ни разу не сталкивался, когда бы такое знание понадобилось.

Оно обычно также остаётся в системе, через которую ставятся задачи. У нас, например, изменение требований обязательно должно было отображаться в жире. По коммитам это всё равно затруднительно понять.

А если не стараться линеаризовать историю - то открываешь историю - а там какой-то абсолютно непонятный guitar hero, как его не крути. Что куда мержилось, что откуда бралось, совершенно непонятно, требуется прям серьёзная археология.

Оно обычно также остаётся в системе, через которую ставятся задачи. У нас, например, изменение требований обязательно должно было отображаться в жире. По коммитам это всё равно затруднительно понять.

Всё равно, Джира это не код.

Хорошо. Вот вы (сторонники одного коммита ту рул зем ол) мне объясните как вы code review смотрите. Есть ПР на 1.5К строк. К нему добавили небольшие правки с помощью --amend. Как вы проверяете этот ПР снова?
Мне достаточно глянуть новый коммит на 10 строк.

Я выше писал, почему это плохо.

да вот как-то нет. там есть вот такой вот рассказ:

я просмотрел чей-то ПР, насыпал коментов, и потом захожу — а там нету оригинального кода. Как мне понять теперь, добавил ли он изменения согласно моим комментариям или нет???

оно во-первых, никакого отношения непосредственно к git не имеет, а больше к инфраструктуре, которая работает с этими ПР, во-вторых, тот же GitLab вполне себе переживает rebase и его производные и замечания не рушатся, ровно впрочем как и GitHub

а там нету оригинального кода

Это не имеет отношения к git? Странно.

В Гитлабе можно увидеть удаленные коммиты и сравнить с новыми? Я с Гитлабом работал неоднократно, но у нас тогда историю не переписывал никто.

Это не имеет отношения к git? Странно.

ну есть у него GC и есть, когда-то можно через reflog выцепить потеряхи, когда-то нельзя, все равно там обсуждений нет никаких. Ну вот даже если это настолько важно на ваш взгляд, то нет в git обсуждений и все - не завезли, т.е. авторам консистентность обсуждений не показалась чем-то важным совершенно.

В Гитлабе можно увидеть удаленные коммиты и сравнить с новыми?

конечно можно. оно все в действительности в БД фиксирует и как-то умудряется толи правильно их связывать, толи там какая-то эвристика на этот счет. Типичная боль тут обратная: попытаться вытереть коммит из его истории.

Есть ПР на 1.5К строк. К нему добавили небольшие правки с помощью –amend. Как вы проверяете этот ПР снова?

Такие вещи не делаются. У каждого есть понимание, что можно делать, а что - нельзя.

Если правится, например, замечание от линтера или от человека по стилю кода (типа CamelCase вместо snake_case), то допустимо во время ревью для этого использовать amend.

Если правится логика, то конечно это недопустимо. Это как бы очевидно для любого разумного человека.

ну есть у него GC и есть, когда-то можно через reflog выцепить потеряхи, когда-то нельзя, все равно там обсуждений нет никаких. Ну вот даже если это настолько важно на ваш взгляд, то нет в git обсуждений и все - не завезли, т.е. авторам консистентность обсуждений не показалась чем-то важным совершенно.

Обсуждения есть в Github/Jira/email/Slack/бумажка. В них теперь ссылка на несуществующий коммит. :)

|<------ Это мастер с кучей коммитов.
|   |<-- Вот это твоя ветка
o   |
o   |
|   | 
o   (2) Время шло, люди работали и комитили в master ветку
|   |          Накапливались конфликты с твой веткой
|   |
...   
|   |
|   o
o   o
o___/ 
o    \
|     (1) Когда-то ты создал ветку для новой фичи 

Теперь тебе надо просто взять и переместить свои старые комиты на верхушку текущего мастера:

Master
<Head>    =>     Твоя ветка
|                   |
o                   o
o          Master   o
|          <Head>__/ 
o               |         
|               o  
...             o
|   |           |
|   o           o
o   o           |
o___/     => 
o   Твоя             
|   ветка            

Это делает команда git rebase. Что тебе нужно выполнить:

git pull origin master # Поднять самые последние изменения в master
git checkout <твоя ветка>
git rebase master      # Переместить коммиты твоей текущей ветки на вершку мастера (как на рисунке выше)

# rebase накатывает твои коммиты на верхушку один за другим 
# как ты закомитил свои коммиты в той последовательности и накатывает (не все сразу).
# как только конкретный коммит содержит конфликт rebase приостанавливается и ожидает что разработчик решит конфликт

git status -sb         # Увидеть конфликты, конфликтные файлы будут помечены через UU.

# Исправить конфликты, используй какой-нибудь diff тулл

git add -A .
git commit --amend 

git rebase --continue # Ты сообщаешь гит что ты решил конфликт в одном коммите и теперь хочешь продолжить накатить оставшиеся.

# Если будут опять конфликты то повторить (status -sb, резолв и --continue)

# Если не хочешь продолжать есть rebase --abort чтоб все отменить.

Ну и про squash (слитие множества коммитов в один)

git rebase --interactive HEAD~<n>

Где - число коммитов в твоей ветке. Например у тебя 3 коммита и ты хочешь сделать из них один:

git rebase --interactive HEAD~3

Откроется твой любимый текстовый редактор в котором будут эти 3-е коммита

pick a5f4a0d Commit 1 Самый первый
pick 310154e Commit 2
pick f7f3f6d Commit 3 Самый последний

Вот тут заменяешь pick на squash во всех последующих последующих коммитах

pick a5f4a0d Commit 1 Самый первый
squash 310154e Commit 2
squash f7f3f6d Commit 3 Самый последний

Слово squash как раз и говорит git что нужно взять «Commit 2» слить в «Commit 1», затем взять «Commit 3» и опять слить в «Commit 1». Остается только «Commit 1» включающий в себя изменения из «Commit 2» и «Commit 3»

Сохраняешь изменения и выходишь. Git делает squash. Пушишь в свою ветку на ремоут.

Сохраняешь изменения и выходишь.

А прикинь, ТС ошибся и ему rebase не уперлась в нужно просто merge ;)

Обсуждения есть в Github/Jira/email/Slack/бумажка. В них теперь ссылка на несуществующий коммит. :)

ничего не понял… ссылки на коммиты в гитлабе хранятся до потери пульса, т.е. вне зависимости от того что там «чудит» котрибьютор, в гитлабе можно увидеть как именно он чудит. Меж тем ссылаться на них в багтрекере - идея так себе же: там завтра адреса поменяются, еще что и все протухнет, а мы тут переживаем за коммиты какие-то.

Мне это на самом деле не особо важно, потому что на review я всегда выкачиваю бранч контрибьютора и смотрю что там происходит, читать так: я уже давно сознал, что через вебуй ничего наревьюивить нельзя, т.е. таки да, каждый раз все начинается сначала (здесь появляется разделение на хороших контрибьюторов и плохих)

Именно поэтому ПР должен быть разбит на понятные куски, каждый из которых можно посмотреть и выдать свои замечания, да, здесь можно условно скроить и ПР на куски не бить (плохой контрибьютор), но тогда придется смириться с тем, что в случае проблем откатываться оно будет полностью, а не именно интеграция с апстримом (плохой контрибьютор должен страдать)

История должна отображать то, что происходило.

Не должна. git log это не система аудита. История должна быть полезна тем, кто будет работать с кодом в будущем. А если история представляет из себя неюзабельный граф и ей никто не пользуется, то она просто не нужна, совсем. Это так, философия.

Если задачу пилили в отдельной ветке месяц и по ходу дела менялось и ее понимание и требования то это должно отображаться в истории. А линейная ничего из этого не отображает.

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

Делать ли squash всех рабочих коммитов в один, теряя всю историю - это вопрос дискуссионный и я это не поддерживаю, хотя есть люди, которые в git коммитят бездумно, и пользы от таких коммитов ноль в любом случае. Но к вопросу о rebase это вообще никак не относится. Ты можешь делать rebase, сохраняя все исходные коммиты, и ты можешь делать merge, предварительно сквашивая все коммиты ветки.

Не должна. git log это не система аудита. История должна быть полезна тем, кто будет работать с кодом в будущем. А если история представляет из себя неюзабельный граф и ей никто не пользуется, то она просто не нужна, совсем. Это так, философия.

Особенно удивительно, что одни и те же люди могут быть категорически против слияний в системах миграций БД (которые тоже являются DAG’ами), но при это топить за слияния вместо rebase в VCS.

Не должна. git log это не система аудита.

Ещё как. Обнаружили в Linux дырку — сразу ищут кто и как ее добавил. Один git blame тут не поможет.

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

Это не те коммиты, это новые, похожие на старые. У них даже хеш разный, что как-бы намекает.

Ты можешь делать rebase, сохраняя все исходные коммиты, и ты можешь делать merge, предварительно сквашивая все коммиты ветки.

Ты никак не проверишь, что нове reabase'нутые коммиты это старые. Старых уже нет.
То что ты называешь «сохраняя все исходные коммиты» это неверно. Коммит это конкретный объект в графе. И его удалили.

Вот, кстати, сподобился почитать про darcs и pijul: там как раз получается история вытянутая в линию, потому что нет необходимости на каждый чих выполнять merge. И это - достоинство, а не недостаток.

Вариант 4 - берёшь нормальную ide, там обычно есть утилита для ребейза и конфликтов

В Гитлабе можно увидеть удаленные коммиты и сравнить с новыми?

могу предположить, что оно при PR review gitlab учитывает patch id (https://git-scm.com/docs/git-patch-id), а не commit id.

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

Это в чистом виде проблема git`а. Он не поддерживает персистентные ветки (соответственно не хранит информацию о принадлежности каждого коммита к определенной ветке). В других VCS нет проблемы отобразить линейно каждую ветку, как и точки слияния между ними.

Либо делать один merge коммит в главную ветку, а рядом подвязывать оригинальную историю коммитов параллельной веткой.

Здравая мысль! Только как их «подвязывать»? Разе что через комменты, т.е. штатных машиночитаемых метаданных не предусмотрено. :-(

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

по умолчанию committer date перезаписывается, author date - остается. Но это поведение изменяемо опциями --committer-date-is-author-date, --reset-author-date и зависит от опции --no-ff.

Либо делать один merge коммит в главную ветку, а рядом подвязывать оригинальную историю коммитов параллельной веткой.

Здравая мысль! Только как их «подвязывать»? Разе что через комменты, т.е. штатных машиночитаемых метаданных не предусмотрено. :-(

Это просто обычный merge, который должен был бы быть fast-forward, но без fast-forward (git switch main && git merge --no-ff branch). История выглядит как-то так:

*   bab1a23 (HEAD -> master) Merge branch 'b2'
|\
| * 4b0d762 (b2) c6
| * b4b9858 c5
| * 916e631 c4
|/
*   d03d1b3 Merge branch 'b'
|\
| * e526a03 (b) c3
| * 8189663 c2
|/
* 0e24627 c1

Это не те коммиты, это новые, похожие на старые. У них даже хеш разный, что как-бы намекает.

тут вероятно изначально некое недопонимание возникает на мой взгляд. Вот в чем изначально заключается беда-то:

лично у меня существует определенное предпочтение, что я хочу потенциально опасные изменения выключать при помощи revert и тем самым обозначать, что вот этот вот конкретный коммит привел к ошибке, мои ожидания со стороны контрибьютора выливаются в одно из двух:

• либо у него в ПР внедрение фичи как-то более-менее размечено, т.е. есть коммиты «здесь у нас лайтово», а «здесь может что-то поломаться»
• либо я откатываю весь ПР целиком

и в том и в другом случае выходит так, что если контрибьютор имел склонность постоянно подмерживать upstream вместо выполнения rebase, то я, как мейнтейнер всего этого добра, теряю возможность сделать revert, вместо этого мне нужно будет идти в багтрекинг, изливать туда свою душу, откатывать изменения вручную, делать новый ПР и пр. - в действительности мне это нафиг не упало и я со своей стороны предъявляю определенные требования к ПР, которые еще и довольно либеральные, а именно: ПР не должен содержать слияний с апстримом, если возникают конфликты, то всегда нужно делать rebase, при этом rebase выполняется контрибьютором, поэтому принадлежность изменений здесь никуда не девается (тут, правда, теряется тема, про то, что хотелось бы, чтобы каждый коммит был самодостаточным)

История выглядит как-то так:

а, ну в этом случае нужно запрещать fast-forward merge в master, иначе линейную историю master отобразить в общем случае будет невозможно.
В команде (и даже нескольких) прийти к такому консенсусу (о запрещении Ff) непросто.

мне сначала показалось, что предлагается вариант git merge --squash с сохранением feature ветки.

как мейнтейнер всего этого добра, теряю возможность сделать revert

Разве? Ты просто откатываешь merge commit. Git позволяет это сделать (--mainline).

ПР не должен содержать слияний с апстримом, если возникают конфликты, то всегда нужно делать rebase, при этом rebase выполняется контрибьютором, поэтому принадлежность изменений здесь никуда не девается (тут, правда, теряется тема, про то, что хотелось бы, чтобы каждый коммит был самодостаточным)

Я, как автор ветки (ПР), теряю историю (код). У меня была ф-ция foo — теперь её нет и в истории никак не найти. Это плохо и неправильно.
Или у меня была ф-ция foo, я в результате разрешения конфликтов сломал её. Как теперь мне увидать какой она была до конфликтов? Правильно — никак.
Это большая проблема и, по моему глубокому убеждению, неверное использование git'а. Я не хочу терять свой код и хочу иметь возможность увидеть любую его прошлую версию.

Разве? Ты просто откатываешь merge commit. Git позволяет это сделать (–mainline).

конечно теряю: я хочу, чтобы в идеале ПР был разбит на осмысленные коммиты/фазы: здесь у нас подготовка к разработке новой фичи, и она ничего не ломает; здесь у нас новая фича которая существует вне приложения, ее можно уже щупать, писать тесты и пр.; здесь у нас интеграция фичи в приложение, которая уже может что-то сломать. И я хочу откатывать не точку слияния, а непосредственно интеграцию: придерживаться этого правила, то контрибьютор даже в случае неуспеха освобождается от последующих трудностей, связанных с поддержкой его нетленки в актуальном состоянии - фича уже попала в ветку разработки и она в том или ином виде будет сопровождаться остальными разработчиками.

Я, как автор ветки (ПР), теряю историю (код). У меня была ф-ция foo — теперь её нет и в истории никак не найти. Это плохо и неправильно.

мне фрустации контрибьютора совершенно неинтересны, он названия своих функций может хоть по 10 раз на дню менять, однако это совершенно не является поводом оформлять этот поток сознания в виде коммитов и загрязнять историю. Более того, я, как и подавляющее количество разработчиков, совершенно не ожидаю при выполнении blame наблюдать записи вида: «исправления после review», «исправлены конфликты», «я тут передумал и решил, что должно называться иначе», «рефакторинг» и пр., после чего спускаться куда-то ниже по истории с целью понять что же на самом деле автор изначально имел в виду и почему так сделано.

Я не хочу терять свой код и хочу иметь возможность увидеть любую его прошлую версию.

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

Я не о «я тут передумал и решил, что должно называться иначе». А о том, что новый код в моей ветке будет развиваться по мере развития твоего кода в мастере.

не ожидаю при выполнении blame наблюдать записи вида: «исправления после review»

Так не лучше ли запретить такие описания коммитов?

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

И два раза решать конфликты. Спасибо.

Так не лучше ли запретить такие описания коммитов?

конечно запретить, только вы же при этом топите за то, что в ПР merge делать, а не rebase, а мержем коммиты не схопываются какая альтернатива-то? reset и push --force

И два раза решать конфликты. Спасибо.

если там все ровно изначально, то конфликтов не будет, ну а если не особо-то и ровно, то какие вопросы к апстриму?

конечно теряю: я хочу, чтобы в идеале ПР был разбит на осмысленные коммиты/фазы:

В идеале, оно, наверное, удобно. А на практике:

1. Я не хочу, чтобы за мной был такой контроль. Я могу начать делать фичу одним образом, понять, что затупил, и сделать совсем другим. Я не хочу, чтобы все мои черновики были видны всем, чтобы каждый мог мне за плечо заглянуть.
2. Для 95% разработчиков всё это всё равно мумбо-юмбо, для них, Git - это что-то типа файлообменника для обмена кодом с коллегами. Они не вникают, и никогда не вникнут. И будут херачить коммиты вида «fixes», «work» до посинения. Можно повесить всюду фашистские хуки и запреты, но это - другая крайность, которая мне тоже не нравится.