Действительно ли история версий священна или лучше перебазировать?

Я всегда соглашался с мантрой Mercurial ¹ , однако теперь, когда Mercurial поставляется в комплекте с расширением rebase и это популярная практика в git, мне интересно, можно ли это действительно рассматривать как «плохую практику», или, по крайней мере, достаточно плохо, чтобы избежать использования. В любом случае, я знаю, что перебазирование опасно после толчка.

OTOH, я вижу смысл пытаться упаковать 5 коммитов в один, чтобы он выглядел лучше (особенно в производственной ветке), однако лично я думаю, что было бы лучше увидеть частичные коммиты для функции, где некоторые экспериментирование сделано, даже если оно не такое изящное, но видя что-то вроде «Пытался сделать так, как X, но это не так оптимально, как Y, в конце концов, делая это Z, принимая Y в качестве основы», ИМХО имело бы хорошее значение для тех, кто изучает кодовая база и следите за ходом мысли разработчиков.

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

Итак, мой вопрос: действительно ли вы нашли ценным иметь такие «органические коммиты» (то есть незапятнанную историю) на практике? Или, наоборот, вы предпочитаете сталкиваться с изящными хорошо упакованными коммитами и игнорировать процесс экспериментов программистов ?; какой бы вы ни выбрали, почему это работает для вас? (наличие других членов команды, чтобы сохранить историю, или, наоборот, перебазировать ее).

¹ на анализ Google DVCS в Mercurial «История священна».

История священна, то Present нет. Вы можете разделить ваше дерево DVCS на две части:

• Прошлая / история , которая содержит точное представление о том, как вы достигли текущего состояния кода. Эта часть истории растет со временем

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

Каждый код, который вы выпустили или каким-то образом использовали, является частью прошлого . Прошлое свято, потому что вы должны быть в состоянии воспроизвести установку или понять, что привело к регрессии. Вы никогда не будете переписывать прошлое . В git вы, как правило, никогда ничего не переписываете, когда он находится в master: master - это последняя часть истории. В Mercurial у вас есть концепция публичной фазы, которая отслеживает прошлую часть вашего «дерева» и обеспечивает его неизменность.

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

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

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

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

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

С другой стороны, ребаз не рекомендуется, если коммиты не имеют ничего общего друг с другом. Многочисленные добавления функций должны быть отдельными коммитами (и в идеале должны быть из разных веток).

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

Я не думаю, что органические рабочие процессы делают это хорошо, даже мои собственные. Качества, которые я ценю в DVCS при кодировании - дешевые ветки, быстрые фиксации, раннее и частое сохранение на удаленном компьютере - не то, что я ценю как менеджер по интеграции моей компании . Я вопрос git rebase, git merge, git diffи git applyгораздо чаще в этой роли , чем git addили git commit. Такие инструменты, как rebaseпозволяют мне преобразовать код, который мне дают, из чего-то, что функционирует, во что-то, что можно поддерживать.

Нелогичные или расплывчатые коммиты бесполезны, но их греховно легко написать органически, когда главная задача - заставить код работать, а не распространять его среди других. Коммиты, как Case 15: Fixed a problem, или Refactored <cranky legacy feature>заставляют мое самообслуживание съеживаться, даже когда я их автор. Ни один, однако, не вызывает ярость затемнения как "постепенные" коммиты. Рассмотрите эту ветку темы, которую разработчик передал мне на днях:

$ git log production..topic --oneline
f9a1184 incremental update
156d299 incremental commits
e8d50b0 new incremental updates
511c18c incremental updates, refactor
1b46217 incremental upgrade
9e2b3b8 incremental update
fa68a87 incremental update

Эти вещи злые. Это как DVCS для доктора Фауста. Я дам вам быстрый и простой контроль над источниками. Вы даете мне, это ваша душа хранителя кода. Все ленивые коммиты - это эгоистичные поступки. Многие из нас пишут их, но мы также обязаны своим будущим логической, воспроизводимой, отлаживаемой историей. Мы не можем сделать это без какого-либо пути rebase.

Что касается неудачных экспериментов, почему бы не описать их в наших (недавно нетронутых) сообщениях о коммитах? Через год мне не нужен полуфабрикат. Мне просто нужна запись о прерванной попытке и, возможно, краткое объяснение, если я считаю себя достаточно глупым, чтобы попытаться снова. В мире существует множество успешных рабочих процессов, но я изо всех сил пытаюсь придумать причину, по которой я бы сознательно фиксировал неработающий код в производственной кодовой базе.

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

Лично я считаю очень полезным перебазировать локальную ветвь функций в ствол (или основную ветку разработки) перед запуском финальных тестов и объединением этой функции с основной веткой. Таким образом, я получаю дело с любыми конфликтами слияния и т. Д. До фактического слияния.

ИМХО, эксперименты обычно относятся к полкам или временным ветвям, а не к исходным. Если вы следуете этому, не должно быть проблемы, так как все коммиты будут логически обоснованы и добавят некоторую ценность.