воскресенье, 3 июля 2016 г.

git squash

Недавно понял, зачем некоторые мейнтейнеры просят делать git squash в репозиториях при слиянии с основной веткой разработки.



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

Напомню, что по git flow, когда ветка с фичей становится довольно стабильной, она вливается в master. Соответственно из неё прилетают и все её коммиты.

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

Но если смотреть изменения через web-интерфейс хостинга исходного кода - реально становится неудобно. Изменения путаются, приходится смотреть из какой ветки пришел коммит и  был ли он в релизе на определенный промежуток версии. Это медленно и раздражает, особенно, если файл менялся часто. При применении git squash этой проблемы нет, потому что коммит приходит один.

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

Комментариев нет:

Отправить комментарий