Alex_Wilson
New member
За свою карьеру я успел поработать и в маленьких стартапах из трёх человек, и в крупной продуктовой команде, где над одной кодовой базой трудились больше сорока разработчиков. И честно скажу: первые полгода в большой команде я ненавидел Git. Половина моего рабочего времени уходила не на код, а на разбор конфликтов слияния, переписывание истории и тушение пожаров перед релизом. Ситуация изменилась не тогда, когда мы выучили какую-то волшебную команду, а когда договорились о шести простых правилах и начали их соблюдать все, включая тимлидов. Ниже я разберу эти правила так, как сам их понимаю, и расскажу, что они дали нам на практике.
Правило первое: короткие ветки. Мы ввели жёсткое негласное правило, что ветка живёт максимум два или три дня, а в идеале укладывается в один рабочий день. Чем дольше ветка стоит в стороне от главной, тем больше кода в ней накапливается и тем болезненнее потом слияние. Раньше у нас были ветки, которые висели по три недели, и встреча с ними всегда заканчивалась вечером, полным ручных правок. Сейчас я стараюсь разбивать задачу так, чтобы каждый кусок можно было влить в основную ветку отдельно, даже если функциональность ещё не включена для пользователей.
Правило второе: маленькие коммиты и небольшие пул-реквесты. Наш ориентир — не больше трёхсот-четырёхсот изменённых строк в одном запросе на слияние. Большой реквест невозможно нормально отревьюить, в нём легко пропустить ошибку, и он почти гарантированно конфликтует с параллельной работой коллег. Когда я начал дробить свою работу на части, я заметил забавную вещь: ревью стало занимать у коллег не час, а десять минут, и замечаний приходило меньше. Люди просто успевали вникнуть в суть, а не пролистывали diff по диагонали.
Правило третье: перед слиянием я сам привожу свою ветку в актуальное состояние. Мой рабочий ритуал выглядит так: забираю свежие изменения из главной ветки, делаю перебазирование своей ветки поверх них и разрешаю конфликты локально, на своей машине. Я считаю это вопросом уважения к коллегам: невежливо перекладывать разбор конфликта на того, кто будет сливать мой код. Заодно я вижу, что именно сломалось, и часто сам понимаю, что моя правка устарела ещё до ревью.
Правило четвёртое: осмысленная история коммитов. Мы договорились о едином стиле сообщений, где указан тип изменения, затронутая область и короткая суть. Звучит бюрократично, но эффект оказался огромным. Когда мне нужно понять, почему в биллинге появилась странная проверка, я открываю историю файла и читаю её как журнал событий, а не как набор строк вроде «фикс» и «ещё правки». Это правило экономит часы при разборе инцидентов на проде и очень помогает новичкам входить в проект.
Правило пятое: быстрый код-ревью и понятное владение файлами. У нас появился дежурный ревьюер, который в первую очередь смотрит входящие запросы, и договорённость не оставлять чужой пул-реквест без ответа дольше нескольких часов. Плюс мы честно признали, что есть зоны, где лучше лишний раз спросить владельца модуля, чем смело переписывать чужую логику. Это снизило количество конфликтов не только в Git, но и в человеческих отношениях, а мне, признаться, второе нравится даже больше.
Правило шестое: автоматизация и предсказуемый ритм релизов. У нас настроена непрерывная интеграция, главная ветка защищена от прямых пушей, тяжёлые миграции и опасные изменения мы выкатываем за флагами, а релизы идут часто и небольшими порциями. Когда релиз перестаёт быть событием месяца, страх перед слиянием исчезает. За последний год у меня случилось всего два серьёзных конфликта, и оба раза мы разобрали их спокойно, потому что изменения были мелкими и понятными.
Итог для меня простой: Git не делает команду медленной, её делает медленной несогласованность. Шесть этих правил не требуют дорогих инструментов или отдельного человека, который будет следить за порядком. Достаточно один раз честно обсудить их на ретро и потом напоминать друг другу, особенно когда дедлайн давит и хочется побыстрее запушить всё одной кучей. Именно в такие моменты дисциплина и окупается.
А какие приёмы помогают вашей команде не тонуть в конфликтах слияния и выпускать релизы без ночных авралов? Расскажите в комментариях, что у вас реально прижилось, а что осталось красивой идеей из доклада на конференции.
Правило первое: короткие ветки. Мы ввели жёсткое негласное правило, что ветка живёт максимум два или три дня, а в идеале укладывается в один рабочий день. Чем дольше ветка стоит в стороне от главной, тем больше кода в ней накапливается и тем болезненнее потом слияние. Раньше у нас были ветки, которые висели по три недели, и встреча с ними всегда заканчивалась вечером, полным ручных правок. Сейчас я стараюсь разбивать задачу так, чтобы каждый кусок можно было влить в основную ветку отдельно, даже если функциональность ещё не включена для пользователей.
Правило второе: маленькие коммиты и небольшие пул-реквесты. Наш ориентир — не больше трёхсот-четырёхсот изменённых строк в одном запросе на слияние. Большой реквест невозможно нормально отревьюить, в нём легко пропустить ошибку, и он почти гарантированно конфликтует с параллельной работой коллег. Когда я начал дробить свою работу на части, я заметил забавную вещь: ревью стало занимать у коллег не час, а десять минут, и замечаний приходило меньше. Люди просто успевали вникнуть в суть, а не пролистывали diff по диагонали.
Правило третье: перед слиянием я сам привожу свою ветку в актуальное состояние. Мой рабочий ритуал выглядит так: забираю свежие изменения из главной ветки, делаю перебазирование своей ветки поверх них и разрешаю конфликты локально, на своей машине. Я считаю это вопросом уважения к коллегам: невежливо перекладывать разбор конфликта на того, кто будет сливать мой код. Заодно я вижу, что именно сломалось, и часто сам понимаю, что моя правка устарела ещё до ревью.
Правило четвёртое: осмысленная история коммитов. Мы договорились о едином стиле сообщений, где указан тип изменения, затронутая область и короткая суть. Звучит бюрократично, но эффект оказался огромным. Когда мне нужно понять, почему в биллинге появилась странная проверка, я открываю историю файла и читаю её как журнал событий, а не как набор строк вроде «фикс» и «ещё правки». Это правило экономит часы при разборе инцидентов на проде и очень помогает новичкам входить в проект.
Правило пятое: быстрый код-ревью и понятное владение файлами. У нас появился дежурный ревьюер, который в первую очередь смотрит входящие запросы, и договорённость не оставлять чужой пул-реквест без ответа дольше нескольких часов. Плюс мы честно признали, что есть зоны, где лучше лишний раз спросить владельца модуля, чем смело переписывать чужую логику. Это снизило количество конфликтов не только в Git, но и в человеческих отношениях, а мне, признаться, второе нравится даже больше.
Правило шестое: автоматизация и предсказуемый ритм релизов. У нас настроена непрерывная интеграция, главная ветка защищена от прямых пушей, тяжёлые миграции и опасные изменения мы выкатываем за флагами, а релизы идут часто и небольшими порциями. Когда релиз перестаёт быть событием месяца, страх перед слиянием исчезает. За последний год у меня случилось всего два серьёзных конфликта, и оба раза мы разобрали их спокойно, потому что изменения были мелкими и понятными.
Итог для меня простой: Git не делает команду медленной, её делает медленной несогласованность. Шесть этих правил не требуют дорогих инструментов или отдельного человека, который будет следить за порядком. Достаточно один раз честно обсудить их на ретро и потом напоминать друг другу, особенно когда дедлайн давит и хочется побыстрее запушить всё одной кучей. Именно в такие моменты дисциплина и окупается.
А какие приёмы помогают вашей команде не тонуть в конфликтах слияния и выпускать релизы без ночных авралов? Расскажите в комментариях, что у вас реально прижилось, а что осталось красивой идеей из доклада на конференции.