Рубрика «управление разработкой» - 22

На днях вышла прекрасная, хотя и спорная статья — Please, stop using GitFlow! (и еще десяток на эту же тему после нее).

Ее основными тезисами были:

• GitFlow противоречит тезису "ветки должны быть короткоживущими".
  Это важно, потому что чем меньше живет ветка — тем меньше шанс конфликтов (не только git, но и логических)
• GitFlow препятствует rebase-ам, чтобы сохранить merge-коммиты.
  Да, их можно сохранять и при ребейзах, но команды Git Flow не делают этого.
• GitFlow отрицает подход Contunious Delivery, считая, что каждый акт Delivery должен совершаться релиз-инженером, да и в целом можно увидеть, что он ориентирован только на долгий релизный цикл.
• GitFlow не дружит с микросервисами поверх мультирепозиториев (впрочем, тут вообще мало что подходит, это идея, которая всегда плохо заканчивается)

• Но проблема GitFlow в том, что он и с монорепозиториями тоже не дружит.

  Я сам об это споткнулся в процессе дизайна пайплайнов CI: GitFlow чудовищно мешает, когда работает поверх монорепозитория с несколькими deliverables, например, когда в одном репозитории отдельно и бэкэнд, и фронтэнд — уже из-за того, что он позволяет докоммичивать в релизные ветки, могут возникнуть конфликты при обратном мердже, если в один момент времени существует больше, чем одна релизная ветка. Да даже если одна, все равно плохо — в таких условиях надо патчить в принципе релизные механизмы GitFlow, чтобы хоть как-то заработали отдельные релизы сущностей.

Так что делать-то?

Читать полностью »