Гит, zeromq и двойная бухгалтерия

[metaclass]

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

Внезапно, в процессе изучения ZeroMQ я наткнулся на прямую иллюстрацию такой двойной бухгалтерии.
Вот например, стабильная версия 4.0.5, исходники под винду: http://download.zeromq.org/zeromq-4.0.5.zip
Так вот, последние 230 коммитов в changelog этой версии напрочь отсутствуют в https://github.com/zeromq/libzmq
Более того, в этой репе существует сугубо две ветки и ни одного тэга.

Ну, то что мастер не собирается в 2010 студии из-за зависимости от крипто-либы sodium, а rc4.1.0 не собирается из-за отсутствующих файлов msbuild, это тащемта уже мелочи. Но по крайней мере, rc4.1.0 есть в гите.

Comments

[besm6.livejournal.com]

Инструментом там рекомендуется, чтобы код в релизе и код в репозитории того, кто этот релиз выпускает, был одинаковым. У разработчика он может быть каким угодно, пока оный разработчик не надел шляпу релиз-менеджера. А существование (центрального) мастера git вообще не поощряет.

Что же до описанной двойной бухгалтерии, то VCS тут вообще ни при чем. Я неоднократно наблюдал подобное с абсолютно любыми VCS и даже вообще без VCS. И считаю, что это, конечно, бардак, но куда хуже, если в мастер коммитят код в состоянии "у меня все работает", от чего ВНЕЗАПНО все ломается у всех остальных разработчиков проекта.

А еще интереснее бывает, если из такого мастера в этот момент выпускают релиз... Ибо дисциплина "релиз выпускаем из тега, а тег ставим на релизную ветку после того, как в ней прошли все тесты, включая ручные" совершенно перпендикулярна модели работы VCS и наличию VCS как таковой.

[aamonster.livejournal.com]

А что, наличие в репе мусорных веток для экспериментов сильно мешает?
(лично мне проще иметь единый репозиторий, чтобы все-все-все изменения были во всех клонах - просто чтобы не думать, чем клоны различаются, и за это я готов платить наличием в репе мусора... особенно с учётом того факта, что я в один клик могу спрятать из истории всё, кроме предков текущего head)

Ну а насчёт бардака - соглашусь с besm6: не инструмент виноват. Можно не иметь никакой "двойной бухгалтерии" в репе - и выпускать релизы с наложенными патчами, к примеру.
Git вполне позволяет делать всё нормально, а то, что какое-то поведение не отсекает - это решается или административно, или демонами (ну в смысле сборка релиза из выделенного репозитория, push в него проходит через автоматизированные проверки)

[vit-r.livejournal.com]

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

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

[allter-ego.livejournal.com]

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

[vit-r.livejournal.com]

Естественно, не блокируются. Потому что такова человеческая природа.

[allter-ego.livejournal.com]

То ли вы меня не поняли, то ли я - вас.

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

Конфигурационная опция receive.denyNonFastForwards не убедит вас в моей правоте?

[vit-r.livejournal.com]

То ли вы меня не поняли, то ли я - вас.

Второе, конечно.

[allter-ego.livejournal.com]

Вот и поговорили )

[pewpewaction.livejournal.com]

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

[cn92bns.livejournal.com]

о, так ты у нас еще и бухгалтер, метакласс.....

[develop7]

— How do you say DVCS in Hipster?
— Git.

[max630.livejournal.com]

> последние 230 коммитов в changelog этой версии напрочь отсутствуют в

вот же: https://github.com/zeromq/libzmq/commits/master~40 . Не они разве? Там же прямо хеш есть

[metaclass.livejournal.com]

Это RC 4.1.0, он есть. Но не собирается под виндой :)

[max630.livejournal.com]

тогда тут: https://github.com/hintjens/zeromq4-x/commit/98df4b6182b133

[metaclass.livejournal.com]

Ох ты ж блин, нашлось таки.
Ясно, они отдельно держат релизную репу.

[max630.livejournal.com]

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

[nicka-startcev.livejournal.com]

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

в цвс такого трэша не было! и даже в свн такой подлянки не было! да и ващще твоя ветка почему-то растет из жопы, а не от моего кошерного каммита!

[metaclass.livejournal.com]

пуллреквест это гитхабовская содомия, нету такой терминологии в гите.

В норме, разработки ведутся в васиной и твоей ветке, периодически втаскивая мастер c merge или rebase.
По мере завершения работы и тестов, твою ветку либо главный, либо ты сам, если мелкая команда, пушишь в мастер, желательно через --ff-only

В общем, у меня с гитом проблем не было вообще, они могут быть, если его использовать как svn,

[ykaliuta.livejournal.com]

> пуллреквест это гитхабовская содомия, нету такой терминологии в гите.

man git-request-pull

[cottidianus.livejournal.com]

> Так вот, последние 230 коммитов в changelog этой версии напрочь отсутствуют в https://github.com/zeromq/libzmq
Для некоторых интересных проектов не существует новых релизов годами. Коммиты сотнями есть свежие, а бампа нет. Для таких проектов существуют scm-билды.