А зачем ребэйзы? По поводу ветвления хорошая статья

По поводу ветвления хорошая статья

Эта говномузыка будет вечно.

немного поправил ОП

в моих собственных проектах она линейная. мне так нравится

Бгг.

я как-то пытался гуглить pro и contra. но или я прохо гуглил или недочитал. в общем ясности не наступило.

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

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

нет, не делаю. но я не верю что хотя бы половина тех кто делает рибейз делают те проверки

а потом если нужно найти чтото в итории и разобратся, то начинаешь плеваться

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

трол моде

и вообще говорить о идеальной разработке то и изменения должны быть такими что не «изменяют» работу изменений в соседней ветке

Каждый ребейз - это повторение всех проверок, сделанных при разработке ребазируемого набора изменений. Ты это делаешь?

нет, не делаю. но я не верю что хотя бы половина тех кто делает рибейз делают те проверки

Ты фабрикуешь историю, которой никогда не существовало, и делаешь это небрежно. Лжешь группе, в которой работаешь (или в случае персонального проекта - лжешь себе).

короче поделитесь вашими саксес стори, впечатлениями и опытом из реального мира.

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

во, наконец-то реальный отзыв.

уточни пожалуйста как провеляли «только верхний» коммит

А зачем ребэйзить? Человек делает себе мерж главной ветки и создает мержреквест. А там уже дифф ревьювить.

если скрытая ошибка есть, она всплывет не зависимо от тила влияния в более основную ветку

что бы небыло такого

http://tau.rghost.ru/private/8ZG9G4c9F/b23098a18fee5fe239a8eedd85c7c7e9/image...

если скрытая ошибка есть,

Речь о том, что ошибка может быть _внесена_ ребейзом.

что бы небыло такого

А что не так? Параллельная работа - это реальность.

еще раз обновил ОП.

не вижу как в случае ребейза может быть ошибка а в случае с мерджем нет

ведь изменеия не меняются. меняется только parent commit

На мой не разумный взгляд дерево легче читается. Т.е. ты сразу видишь, что и куда идет и во что в конце концов вливается.

По этому я использую --no-ff у меня стоит глобально.

Собрать, все тесты прогнать, запустить потыкать (если есть интерфейс). В общем, убедится, что ребейз не накосячил. Если что-то не так, то уже выяснять что случилось более детально.

А зачем ребэйзить? Человек делает себе мерж главной ветки

Как раз чтобы не делать этот мерж, он историю делает плохо читаемой. Это визуально напряжно оценивать (если идут, скажем, 5 «линий» и пересекаются в разных местах) и git bisect потом мечется между такими мержами.

В общем, так история более структурирована. Это конечно не критично, но если есть возможность держать её в таком виде, то почему бы и нет. И при копании в поисках причин изменений, это делает жизнь немного проще.

не вижу как в случае ребейза может быть ошибка а в случае с мерджем нет

В случае мержа ошибка локализована в мерже, а в случае ребейза может проявиться в любом из цепочки коммитов.

На вкус и цвет... Мне удобнее смотреть историю с мержами. А чтобы не копаться в причинах, надо юниттесты внедрять и гонять их постоянно.

Review вроде не должны мешать делать rebase, если, конечно, они делаются до вливания кода в основную ветку.

То ещё нормально, главное чтобы не было чего-то такого (это bionic, если что, у них после таких мержей ещё накатываются «revert revert revert revert revert ...»).

+мульен. вы поняли о чем речь в ОП

это п..дец. как они в этом разбираются?

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

Судя по количеству откатов коммитов — плохо. Вообще это более-менее старая история, текущая выглядит получше (до 5-7 столбцов). Искал там когда-то изменения связанные с pthreads, не понравилось такое разглядывать. Поэтому предпочитаю

*   Merge branch ...
|\
| * change n
| ...
| * change 1
|/
*   Merge branch ...
|\
...

Если что, тут ветки не бесполезные, они задают контекст коммитам (особенно вместе с комментариями в merge-коммите), хотя технически можно было и fast-forward делать.

спс.

с перевесом в 1 голос победила комманда любителей мерджа

сабж

Делай как тебе нравится, оба варианта замечательно применимы.

Хочется - ребейзи, те кто считает что история должна быть неизменна - безграмотные кретины.

Не хочется - мержи, те кто считает что история с мержами чем-то менее удобна линейной - также безграмотные кретины.

спасибо за мнение.

в своих проектах все понятно.

сложнее в рабочих. я там еще не авторитет, а каши там имо предостаточно. да и если менять воркфлоу, нужно его чем то аргументировать

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

В случае мержа ошибка локализована в мерже, а в случае ребейза может проявиться в любом из цепочки коммитов.

При этом ты пользуешься mq.

И чо такого? Смысл в том, что каждый коммит из «рабочего» состояния дерево исходников снова переводит в «рабочее», mq это касается точно так же. После ребейза же этот инвариант теряется.

mq точно такой же ребейз. И точно также нарушает инварианты.

mq точно такой же ребейз.

Не точно такой же. Во-первых, в «ребейзе» участвуют гораздо меньше изменений, и они все - твои личные; во-вторых, «ребейз» обвычно затрагивает только часть цепочки коммитов; в-третьих, после «ребейза» продолжается работа, так что изменения лучше проверяются.

и они все - твои личные

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

и они все - твои личные

Про не личный ребейз тут речь вроде и не шла

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

Именно в этом отличие ребейза от очереди патчей - в очереди патчей изменения только свои.

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

Но что мешает ребейзить только свои изменения?

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

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

Собственно мои коллеги, не умеющие в mq, так и делают. И мне кажется это вполне естественным.

Естественным было бы осилить mq, тем более, что это несложно. А насчет ребейза - см «в-третьих».

Переходи на gerrit, будет линейность