Недавно понял, зачем некоторые мейнтейнеры просят делать git squash в репозиториях при слиянии с основной веткой разработки.
Заранее напишу, что подробное обсуждение данного вопроса есть здесь . Там же и приведены довольно интересные дискуссии на эту тему, и описан хороший способ управления изменениями. Но для тех, кому лень читать тот длинный пост, напишу о своём кейсе.
Напомню, что по git flow, когда ветка с фичей становится довольно стабильной, она вливается в master. Соответственно из неё прилетают и все её коммиты.
Допустим, нам нужно проследить состояние какого-то файла на определенный момент, желательно с динамикой изменения по релизам. Если у нас есть набор релизов в виде tarball - то все хорошо, по ним это сделать относительно легко.
Но если смотреть изменения через web-интерфейс хостинга исходного кода - реально становится неудобно. Изменения путаются, приходится смотреть из какой ветки пришел коммит и был ли он в релизе на определенный промежуток версии. Это медленно и раздражает, особенно, если файл менялся часто. При применении git squash этой проблемы нет, потому что коммит приходит один.
Конечно, поклонники атомарности возразят, потому что коммит в таком случае будет содержать просто кучу изменений - но тут уж стоит решить самому, что важнее. Ну или взять на заметку способ, описанный выше.
Конечно, поклонники атомарности возразят, потому что коммит в таком случае будет содержать просто кучу изменений - но тут уж стоит решить самому, что важнее. Ну или взять на заметку способ, описанный выше.
Комментариев нет:
Отправить комментарий