Сохранение истории коммитов контроля версий и рефакторинга и документации

Практически ничего не стоит использовать историю коммитов, поддерживаемую системой контроля версий. Тем не менее, во время крупного проекта по рефакторингу (или реорганизации / очистке) функции и классы и даже пространства имен будут перемещаться; иногда несколько файлов будут объединены вместе, а другие файлы будут разделены. Эти изменения часто приводят к потере исходной истории фиксации нескольких файлов.

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

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

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

Играет ли история принятия исходного кода какую-либо роль в общении между членами команды? Что если мы отменим историю коммитов, а вместо этого будем полагаться на «исходный код» + «код модульного тестирования» для связи?

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

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

Пока последняя версия продолжает удовлетворять всем требованиям к программному обеспечению, нужно ли нам на самом деле сохранять историю исходного кода?

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

Предположим, вы используете версию 7.8 вашей программы. Но вы поддерживаете на местах 12 различных активных версий, таких как 1.6, 2.2, 2.8 и так далее. Каждый из них не будет обновлен до последней версии по разным причинам, поэтому вы поддерживаете все исправлениями ошибок. Клиент обнаружил ошибку в вашей последней версии 7.8. Вы исправите это в 7.8. Откуда вы знаете, сколько других релизов нужно исправить? Без истории источника и отслеживания проблем вы не сможете.

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

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

Кроме того, могут быть очень веские юридические причины для хранения истории исходного кода. Большая часть погружений в исходный код, которые мне приходилось делать (в качестве инженера по сборке / SCM), была по запросу юридического отдела моей компании.

Пока последняя версия продолжает удовлетворять всем требованиям к программному обеспечению, нужно ли нам на самом деле сохранять историю исходного кода?

Но помимо этого, есть ли смысл хранить историю коммитов исходного кода?

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

Играет ли история принятия исходного кода какую-либо роль в общении между членами команды? Что если мы отменим историю коммитов, а вместо этого будем полагаться на «исходный код» + «код модульного тестирования» для связи?

Да. Подход только «исходный код» + «код модульного тестирования» не говорит вам, кто / когда / почему.

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

Я полагаю, вы могли бы сказать, что это так. Но лишь немногие разработчики тщательно документируют изменения в требованиях / дизайне. И, конечно, почти никто не записывает поток мыслей, который привел к первоначальному развитию или последующим модификациям. Наличие истории коммитов (и особенно сообщений журнала коммитов) и перекрестных ссылок на систему отслеживания проблем / ошибок, по крайней мере, предоставят вам что-то, из чего можно пойти. И это лучше, чем ничего, или набор снимков релиза.