Мне нередко доводилось видеть печальную картину. Человек вроде как умеет работать с Git, знает там всякие git commit и git push , но плохо представляет, что именно с ними нужно делать. На практике это выливается в параллельную работу всей команды над пятью разными бранчами и мержами этих бранчей друг с другом, сорванными сроками потому что «ой, наш билд еще не стабилен», желание смотреть на «карты метро» при помощи IDE или gitk/gitg/tig, уговоры команды взять и дружно заставить себя использовать утилиту gitflow и в прочие ужасные вещи.
Практика показывает, что всех этих, а также других, проблем можно избежать, взяв на вооружение очень простую и понятную модель создания веток. Модель эта, кстати, во многом применима не только для Git, но и для Subversion , Mercurial и других систем контроля версий. На самом деле, то, о чем я собираюсь сейчас рассказать, сильно напоминает уже упомянутый git flow. Но это не совсем git flow. Вообще, git flow очень странен во многих отношениях, а также по моему мнению излишне усложнен.
Итак, в репозитории бывают следующие бранчи.
Ветка master. Это стабильная, на 100% рабочая ветка. Здесь вы создаете тэги (желательно по semver ) из которых собираются билды, предназначенные для stage и prod окружений. Вы никогда-никогда не ломаете master и если мержите в него что-то напрямую, то только очень простые и супер срочные фиксы для прода.
Ветка dev. Эта ветка существует параллельно с master. Это стабильная (!) ветка, в работоспособности которой вы уверены на ~90-95%, предназначенная для test и иногда dev окружений. Если только QA не нашли серьезных проблем в ветке dev, вы можете в любой момент вмержить ее в master и собрать билд для прода. Небольшие фиксы можно мержить сюда напрямую. Также в ветку dev домерживается master, если в нее вносятся срочные исправления для прода.
Фичбранчи (PRJ-1234-short-descr). Эти бранчи ответвляются от dev и непосредственно в них работают разработчики. Один фичбранч — это обычно одна задача из Jira. В названии бранча используется номер таски и краткое его описание, как показано в примере. Работа над фичбранчем не должна сильно затягиваться, на работу над ним должен тратиться один, максимум два дня. Иначе вы рискуете сильно разъехаться с другими ветками. Если работа над одной задачей требует недели работы, скорее всего, вы плохо разбили задачи на части.
Это если в общих словах. При более детальном рассмотрении остается ряд вопросов. Давайте же на все эти вопросы ответим!
Как фичбранчи попадают в dev? Через пулреквесты. Кто-то из ваших коллег проводит code review (кстати, в этом смысле BitBucket довольно удобен), делает замечания, вы исправляете их в фичбранче и обновляете PR. Тут еще важно договориться, чтобы программисты не докапывались друг до друга слишком уж сильно, иначе это скатывается в споры о вкусовщине. PR должен быть отклонен только если в нем что-то сделано ну очень неправильно, в смысле это не будет работать вообще.
Как разрешаются конфликты? Чтобы при мерже не возникало конфликтов перед PR программист должен накатить dev в свой фичбранч (потому что, пока он работал, в dev намержили другие программисты), разрешить конфликты и прогнать тесты. В идеале вообще нужно следить за PR своих коллег и регулярно накатывать себе ветку dev. Бывает еще так, что приходит сразу два PR. Оба ОК, в обоих проходят тесты, оба вмержились в dev без конфликтов. И тут тесты посыпались. Поэтому перед каждым мержем человек, который делает code review, должен у себя локально руками накатывать dev в соответствующий фичбранч и проверять, что это ничего не сломает. Мы же помним, что dev — это стабильная ветка!
Как откатить таску, если она уже в dev? Редко, но такая потребность все же возникает. И это всегда головная боль, потому что другие программисты уже намержили ветку dev в свои фичбранчи, разрешили конфликты, а если теперь все откатить (любым способом, их много), им снова придется все переделывать. Краткий ответ — таски никогда не нужно откатывать . Если таска сложная, постарайтесь реализовать ее, как новую фичу, плюс сделайте флаг, который включает новую фичу и, если она пришла на смену другому поведению, выключает старую. Если таску нужно вообще откатить, заведите новую отдельную таску на выпиливание, и, соответственно, новый фичбранч. Вообще, тут мы касаемся вопроса обратной совместимости и миграций , а это отдельная большая тема. В порядке исключения, если таска небольшая, можно откатить ее revert’ом или иным способом. Но нужно дважды подумать перед тем, как вы решите это делать.
Как не забивать на code review? Как вариант, в команде может быть релиз инженер или тимлид, который на постоянной основе отвечает за code review. Другое решение заключается в том, что любой программист может провести code review, при этом PR не должен висеть более N дней. Если на code review все забивали более N дней, заводится блокер на его проведение и назначается кому-то по принятой схеме распределения задач. Основная идея в том, что PR не должны висеть слишком долго, иначе задачи начинают слишком сильно друг с другом расползаться. Чем быстрее принимаются PR, тем лучше.
А почему нельзя ломать ветку dev? От dev’а создаются новые фичбранчи, а также он постоянно домерживается в уже существующие фичбранчи. Как только наступает конец спринта, в dev за пол дня можно поправить оставшиеся шероховатости и собрать из него билд для stage и prod. Если dev не является стабильной веткой, вы попадаете в мир боли, сорванных сроков и непрерывного разрешения конфликтов.
Хочу отметить, что все написанное выше — проверенная временем, рабочая схема, используемая во многих компаниях. В них когда-то пытались изобретать что-то свое, но в конечном счете, через боль и страдания, приходили к чему-то подобному или очень близкому, со стабильной веткой dev и прочей спецификой. Можете ставить эксперименты сколько угодно, но я уверю вас, что в пределе вы все равно придете к аналогичному решению.
В первом приближении, я рассказал обо всем, что хотел. Возможно, что-то важное я забыл упомянуть, в этом случае не стесняйтесь задавать вопросы в комментариях.
А как вы работаете с системами контроля версий?
