Зачем нам workflow для работы с git?

Чтобы ответить на поставленный вопрос, нам нужно понять:

  • что должен решать workflow для нашей команды?
  • какие задачи мы решаем, организуя наши коммиты, и как мы выпускаем релизы?
  • кто ответственен за код в нашем репозитории и за каждую конкретную правку?
  • какая процедура предложений правок должна быть организована для «внешних» людей?

Благодаря своей распределённой природе git позволяет очень гибко организовывать работу разрозненных команд. В то же время такая гибкость может привести ко множеству ошибок интеграции нового кода в основную ветвь разработки и «выпуску релиза» нашего продукта.

Первое, что предлагает нам git — возможность работы со своим «форком», забирая данные из одного удалённого репозитория и отправляя в другой. Базовые схемы организации такой работы описаны в «Pro Git».

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

А зачем нам разбираться с историей?

С историей разработки нужно уметь обращаться для лучшего понимания того, как использовать наш код нам самим и внешним потребителям. В частности, чтобы ответить на вопросы:

  • как мне участвовать в релизом цикле?
  • какая версия сейчас стабильна?
  • кто и когда сломал код

Workflow позволяет ответить на них заранее.

git-flow

Попытку описать процессы формирования релиза и ответа на похожие вопросы сделал Vincent Driessen в своей статье «A successful Git branching model» и по-русски «Удачная модель ветвления для Git».

В этой статье основной упор делается на решении задач:

  • как вести разработку и не бояться «закопаться» в процедуре формирования релиза
  • как и когда формировать релиз
  • как внешнему (для проекта) пользователю понять где брать стабильный релиз и релиз более старой версии
  • как делать hotfix'ы тогда, когда основная ветвь разработки ушла уже далеко

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

Однако не всем подошли такие процедуры релизного цикла, и уже сейчас у проекта более пятисот «форков».

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

GitHub flow

Хотя git-flow покрывал большую часть задач, GitHub'овцы не могли его использовать из-за своего подхода к «доставке фич в продакшен».

В их подходе делается упор на следующие задачи:

  • как доставить стабильную фичу пользователю как можно раньше
  • как при этом понимать, в какой стадии находится разработка
  • как быстро принимать и тестировать «внешние» правки

Тоесть они реализуют идеи Continuous integration и Continuous deployment для своего процесса.

С критикой git-flow и описанием подхода GitHub можно ознакомиться в статье «Issues with git-flow»

My flow?

Вообще, для каждой команды разработчиков может быть разработан свой метод менеджмента кода. Главное, чтобы этот метод отвечал на требования, поставленные к нему командой.

Ну, а для полноценного «ведения» своего репозитория нужно понимать возможности системы контроля версий, в частности, различия таких команд как git rebase и git merge, когда и как они применяются.

В интернете есть много статей по поводу ведения проектов в git и использования git rebase, git merge, ну и git cherry-pick. Например, статья «Changing history, or How to Git pretty» наглядно показывает, что стоит делать со своей историей, а чего делать не стоит.

Дополнительные ссылки

комментарии Disqus