Философия CI, CD и CD

"Вот если бы было сделано так, что если что то меняешь, то эти файлы остальным доступны только для чтения..." - именно так работает некогда популярная система контроля версий SVN.

Но с появлением Git, система SVN постепенно потеряла свою популярность. Оказалось, что ситуация при которой "если что-то меняешь, остальным доступ к этим файлам только на чтение" как раз таки очень не удобная!

Гораздо удобнее иметь возможность одновременной работы над файлами, в том числе в offline и в асинхронном режиме.

С Git как раз удобно менять разные части одного файла. Кто-то, например, в шаблоне меняет шапку сайта, а кто-то в это время у себя меняет подвал, и при слиянии это безболезненно складывается. Или когда меняют разные части конфигурационного файла. Если кто-то заблокирует конфиг на неделю, то будет неудобо.

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

Согласен. Также делаю.

Подход зависит от выбранного ритма работы и коммуникации с заказчиком.

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

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

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

В этом и смысл. Если разработка классическая, то можно делать всё как угодно хоть месяцами, проверяя всё вручную. Если же это Agile, предполагающий почти ежедневную разработку фич, то там как раз удобны практики экстремального программирования: регулярный обмен кодом, постоянное тестирование работоспособности проекта, регулярный автоделой и т.п. Чтобы точно было понятно, на сколько процентов реально сделана каждая фича на прошлой неделе и чтобы можно было точнее ставить задачи на следующий спринт.