История изменений

ChangeLog — атавизм той эпохи, когда VCS не применялись повсеместно, а патчи пересылались исключительно почтой от одного разработчика другому.

Под словом Changelog можно понимать несколько разных вещей с совершенно разными целями.

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

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

Поскольку git log - вещь неизменяемая, то запись в нём о том что баг X пофикшен не значит по сути ничего. Тремя месяцами позже в том же git log может оказаться запись по типу «Мы думали что баг X пофикшен, но ошибались, и теперь наконец пофиксили его окончательно».

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

При этом никто не мешает генерировать Changelog из лога коммитов в vcs, отфильтровывая лишнее типа «поправил форматирование», «переделал тестовый фреймворк» или «пофиксил предыдущий фикс», группируя коммиты по bug id и записывая результат в подходящий формат.

ChangeLog — атавизм той эпохи, когда VCS не применялись повсеместно, а патчи пересылались исключительно почтой от одного разработчика другому.

Под словом Changelog можно понимать несколько разных вещей с совершенно разными целями.

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

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

Поскольку git log - вещь неизменяемая, то запись в нём о том что баг X пофикшен не значит по сути ничего. Тремя месяцами позже в том же git log может оказаться запись по типу «Мы думали что баг X пофикшен, но ошибались, и теперь наконец пофиксили его окончательно».

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

При этом никто не мешает генерировать Changelog из лога коммитов в vcs, отфильтровывая лишнее типа «поправил форматирование», «переделал тестовый фреймворк» или «пофиксил предыдущий фикс», группируя коммиты по bug id и записывая результат в подходящий формат.