Стоит ли усилий, чтобы создать красивую историю изменений в DVCS?

Question

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

Ты все еще делаешь это? Почему это стоит того, почему ты больше не делаешь это, ты когда-нибудь делал это или думаешь начать?

Если бы я участвовал в разработке ядра Linux, это, очевидно, стоило бы моего времени, потому что в противном случае Линус отклонил бы мой патч, но IMO одна из больших ошибок пользователей dvcs - представить, что их проект похож на ядро ​​Linux. В моих проектах обычно всего несколько разработчиков.

Answer 1

Не стоит усилий.

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

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

Answer 2

Я прилагаю усилия, чтобы очистить мою историю изменений. Мой рабочий процесс идет по принципу небольшого, но значимого редактирования, коммита, повторения до тех пор, пока не будет произведен ряд более крупных изменений. Затем я возвращаюсь и переупорядочиваю / группирую коммиты в функционально атомарные коммиты и выталкиваю эти пересмотренные коммиты. Это позволяет другим разработчикам видеть коммиты, которые создают функциональные различия, в отличие от массивных стен тривиальных коммитов. Облегчает отладку регрессий, когда они происходят.

Answer 3

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

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

Answer 4

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

Answer 5

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

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

Вы также увидите, что новое измерение, которое объединяет, значительно усложняет деление пополам. Это больше не просто влево или вправо.