Зачем нам 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» наглядно показывает, что стоит делать со своей историей, а чего делать не стоит.