Почему ветвление в git — это плохо

Это перевод статьи с dev.to. Оригинал.

Решил перевести в рамках практики не дословного перевода (и даже не по предложениям), а семантического. То есть передать смысл, но избежать корявости текста, характерного для переведённых текстов. А внимание привлекло потому что вопрос актуальный в текущей работе.

С автором согласен — подход очень органичный для CI, но требует очень высокой дисциплины команды (частых коммитов) и автоматизации сборок и базовых тестов.

Многие кодят используя фичебранчи в git. Понятно для чего — не хочется ввязываться в разбор возможных конфликтов в процессе пуллов (с кодом) или после того как ваш пуш сломал что-то для всей команды (с людьми).

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

Группа из пяти человек должна нарисовать большой пейзаж. Они делят холст на пять частей, а затем каждый две недели рисует свою часть даже не глядя на то, что делают остальные. И через две недели они стягивают свои куски обратно в цельный холст создавая, так сказать, единый продукт. Как думаете, что получится? Получится безобразие с невыровненными переходами из элемента в элемент, которые нужно будет перерисовывать перед самой сдачей. Возможно даже всю последнюю ночь. Звучит знакомо?

Однако, как же можно работать в единой ветке без разламывания чужой работы и постоянных конфликтов?

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

Теперь самое страшное — как закоммитить частично готовый кусок и не сломать имеющийся функционал? И как вкоммитить новый функционал, насчёт работоспособности которого ещё не вполне уверен?

Ну ведь одно из самых ключевых преимуществ совместной работы в одной ветке — если что-то сломалось, это будет быстро замечено и быстро починено. На раннем этапе. Что довольно таки безболезненно.

Что же касается того чтобы коммитить недоделанное, есть очень хорошая техника под названием «фича тогглинг» (feature toggling). Достигается она главным образом заданием дополнительного условия на период разработки. Типа такого:

if (useNewLogic) {
    awesomeNewFeatureEntryPoint();
} else {
    legacyEntryPoint();
}

Это позволяет запускать код там, где вы хотите и тогда, когда вы хотите без особого риска всё поломать.

Ещё раз, такой подход обеспечивает преимущество в том, что если ваша фича конфликтует с другим изменением, вы можете выяснить и исправить это быстро. А это значит, что вы практикуете Continuous Integration.

Один из способов перехода на такой формат, более благоприятный для тех, кто привык к разработке в фичебранчах — использовать только две ветки: master и develop. Когда в master изменения попадают только через pull-request.