VCS пошли куда-то не туда

[victor_sudakov]

Я более 20 лет использую системы контроля версий, начинал ещё с RCS, сейчас такую наверное и не помнят. Но вот это для меня звучит полной тарабарщиной:

Squashing commits via the command line using "git merge - squash" is just another time consuming step. That's why we have an option to allow Git users to automatically squash commits in feature branches when merging pull requests. This helps you maintain a clean, easy-to-follow history for your repo.

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

Историей изменений безжалостно манипулируют, перелопачивают, сливают и удаляют changeset-ы, целые ветки пересаживают с места на место в дереве - к чему всё это? Следы запутать? Это тот самый формализм, когда форма становится важнее содержания.

Comments

[constb.livejournal.com]

feature-branch – это термин из git flow, сборника best practices по работе с гитом. и да – на практике бывает необходимость сквошить фичебранчи, элементарно потому что в процессе работы над фичей разрабы часто делают десятки мелких коммитов с нерабочим кодом по множеству причин – чтобы сохранить текущую работу в конце рабочего дня, чтобы задеплоить на тестовый сервак (а гитом деплоят хоть и редко, но бывает), у кого-то компульсивная привычка делать коммит также как делается сейв…

итог – фичебранч заполненный незначительными коммитами без описаний или описания типа "fix" что тоже можно считать что без описания… :) когда фича готова – весь этот поток сознания нет никакой необходимости сохранять для потомков – поэтому делается мерж-сквош и фичебранч удаляется в /dev/null…

дело ещё в том что гит-флоу подразумевает что в develop мержатся только полностью готовые фичи, а исправления, буде таковые понадобятся впоследствии, должны идти отдельными хотфикс-бранчами…

и конечно далеко не все работают по гит-флоу, даже команды которые используют гит-флоу не обязаны всё делить на фичи и хотфиксы и сквош тоже не является обязательным – просто дополнительная возможность…

и конечно красивые патчи – это важно… история разработки дополняет документацию по проекту (если таковая вообще существует) и здорово ускоряет онбоардинг новых разрабов!…

[victor_sudakov]

Описанная манипуляция историей (удаление фичебранчей и т.п.) происходит в индивидуальных репозиториях разработчиков (до пуша) или уже в общем репозитории проекта?

[constb.livejournal.com]

чаще наверное в общем репозитории – во-первых, хорошая привычка сливать всю работу в репу, так как бывает и компы дохнут и винты с данными помирают, во-вторых, если деплой делается гитом, на целевой машине всё равно нужно делать пулл. для небольших фич которые от и до разрабатываются локально, наверное фичебранч вообще не появляется в общей репе, сразу кидается в develop готовый коммит с фичей…

вообще у каждого разработчика свой стиль работы с гитом и свои привычки. я обычно стараюсь коммитить сразу в develop и сразу готовые и протестированные фрагменты кода. иногда могу раз в несколько дней коммитить – это нормально если долгое время один работаешь над проектом, а у меня часто так и есть. кто-то наоборот по десятку коммитов раскидывает за день по разным веткам, а потом это всё начинает собирать мержами, иногда бывает одни фичи начинают ветвление от других фич и начинается бардак…

бывает что делается ветка под мегафичу, которая разрабатывается месяцами и по ходу забывается о том, что вообще-то в проекте есть master и develop и начинается – где правки? какую ветку деплоить? почему не мержили? и все такие ну чего придираешься, некогда было – вот такая вот ветка, в ней всё как надо, её и деплой – тогда хочется гонять всех ссаными тряпками… :) разработчики – такие разработчики… :)

ещё сам гит дерево веток не очень наглядно рисует – в репозитории часто висит вагон старых фич, которые давно смержили и забыли. у меня в Tower сразу видно список, я на своих проектах из origin старые фичебранчи зачищаю руками…

[victor_sudakov]

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