Разработка на основе магистрали против Git Flow

Чтобы разрабатывать качественное программное обеспечение, мы должны иметь возможность отслеживать все изменения и при необходимости отменять их. Системы контроля версий выполняют эту роль, отслеживая историю проекта и помогая объединять изменения, внесенные несколькими людьми. Они значительно ускоряют работу и дают нам возможность легче находить ошибки.

Более того, работа в распределенных командах возможна в основном благодаря этим инструментам. Они позволяют нескольким людям одновременно работать над разными частями проекта, а затем объединять их результаты в единый продукт. Давайте подробнее рассмотрим системы контроля версий и объясним, как возникла транковая разработка и Gitflow.

Как системы контроля версий изменили мир

До того, как были созданы системы контроля версий, люди полагались на ручное резервное копирование предыдущих версий проектов. Они копировали измененные файлы вручную, чтобы объединить работу нескольких разработчиков над одним и тем же проектом.

Это стоило много времени, места на жестком диске и денег.

Когда мы смотрим на историю, мы можем выделить три поколения программного обеспечения для контроля версий.

Давайте посмотрим на них:

Мы заметили, что по мере развития систем контроля версий появляется тенденция к увеличению возможностей параллельной работы над проектами.

Одним из самых революционных изменений стал переход от блокировки файлов к объединению изменений. Это позволило программистам работать более эффективно.

Еще одним значительным улучшением стало внедрение распределенных систем. Git был одним из первых инструментов, вобравших в себя эту философию. Это буквально способствовало процветанию мира с открытым исходным кодом. Git позволяет разработчикам копировать весь репозиторий с помощью операции, называемой разветвлением, и вносить нужные изменения, не беспокоясь о конфликтах слияния.

Позже они могут запустить запрос на вытягивание, чтобы объединить свои изменения с исходным проектом. Если первоначальный разработчик не заинтересован во включении этих изменений из других репозиториев, он может самостоятельно превратить их в отдельные проекты. Все это возможно благодаря тому, что нет понятия центрального хранилища.

Стили разработки

В настоящее время самой популярной системой контроля версий, безусловно, является Git с долей рынка около 70 процентов в 2016 году.

Git был популяризирован с появлением Linux и сцены с открытым исходным кодом в целом. GitHub, в настоящее время самое популярное онлайн-хранилище для общедоступных проектов, также внес значительный вклад в его распространение. Мы обязаны введением простых в управлении запросов на включение в Git.

Проще говоря, запросы на вытягивание — это запросы, созданные разработчиком программного обеспечения для объединения созданных им изменений с основным проектом. Он включает в себя процесс рассмотрения этих изменений. Рецензенты могут вставлять комментарии к каждому элементу, который, по их мнению, можно улучшить или считать ненужным.

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

Git — это просто инструмент. Вы можете использовать его по-разному. В настоящее время вы можете столкнуться с двумя наиболее популярными стилями разработки: Git flow и транковая разработка. Довольно часто люди знакомы с одним из этих стилей и могут пренебречь другим.

Давайте подробнее рассмотрим их обоих и узнаем, как и когда мы должны их использовать.

Git поток

В модели разработки потока Git у вас есть одна основная ветка разработки со строгим доступом к ней. Его часто называют веткой develop .

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

Требуется некоторое время, чтобы согласовать окончательный вариант изменений. После согласования запрос на включение принимается и объединяется с основной веткой. Когда решено, что основная ветка достигла достаточной зрелости для выпуска, создается отдельная ветка для подготовки окончательной версии. Приложение из этой ветки тестируется и исправляются ошибки до момента, когда оно готово к публикации конечным пользователям. Как только это будет сделано, мы объединяем конечный продукт с master веткой и помечаем его релизной версией. Тем временем в ветке develop могут разрабатываться новые функции.

Ниже вы можете увидеть блок-схему Git, изображающую общий рабочий процесс:

Одним из преимуществ Gitflow является строгий контроль. Только авторизованные разработчики могут утверждать изменения после их внимательного изучения. Это гарантирует качество кода и помогает устранять ошибки на ранней стадии.

Тем не менее, вы должны помнить, что это также может быть огромным недостатком. Это создает воронку, замедляющую разработку программного обеспечения. Если скорость является вашей главной задачей, то это может быть серьезной проблемой. Функции, разработанные отдельно, могут создавать долгоживущие ответвления, которые сложно объединить с основным проектом.

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

Более того, пул-реквесты могут привести к чрезмерному микроуправлению, когда ведущий разработчик буквально управляет каждой строкой кода. Если у вас есть опытные разработчики, которым вы можете доверять, они справятся с этим, но вы можете напрасно тратить их время и навыки. Это также может сильно демотивировать разработчиков.

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

Плюсы и минусы Git Flow

Как видите, запросы на вытягивание не всегда могут быть лучшим выбором. Их следует использовать только там, где это уместно.

Когда Git Flow работает лучше всего?

• Когда вы запускаете проект с открытым исходным кодом.
  Этот стиль пришел из мира с открытым исходным кодом, и там он работает лучше всего. Поскольку каждый может внести свой вклад, вы хотите иметь очень строгий доступ ко всем изменениям. Вы хотите иметь возможность проверять каждую строку кода, потому что, честно говоря, вы не можете доверять людям, которые вносят свой вклад. Обычно это некоммерческие проекты, поэтому скорость разработки не имеет значения.

• Когда у вас много младших разработчиков.
  Если вы работаете в основном с младшими разработчиками, вам нужно иметь возможность тщательно проверять их работу. Вы можете дать им несколько советов о том, как сделать что-то более эффективно и помочь им быстрее улучшить свои навыки. Люди, которые принимают запросы на вытягивание, строго контролируют повторяющиеся изменения, чтобы предотвратить ухудшение качества кода.

  

• Когда у вас есть готовый продукт.
  Этот стиль также хорошо работает, когда у вас уже есть успешный продукт. В таких случаях основное внимание обычно уделяется производительности приложения и возможностям нагрузки. Такая оптимизация требует очень точных изменений. Обычно время не является ограничением, поэтому здесь этот стиль хорошо работает. Более того, для этого стиля отлично подходят крупные предприятия. Им необходимо тщательно контролировать каждое изменение, поскольку они не хотят сломать свои многомиллионные инвестиции.

Когда Git Flow может вызвать проблемы?

• Когда вы только начинаете.
  Если вы только начинаете, то Gitflow не для вас. Скорее всего, вы хотите быстро создать минимальный жизнеспособный продукт. Выполнение запросов на вытягивание создает огромное узкое место, которое резко замедляет работу всей команды. Вы просто не можете себе этого позволить. Проблема с Gitflow заключается в том, что запросы на вытягивание могут занимать много времени. Просто так обеспечить быстрое развитие невозможно.

• Когда нужно быстро повторить.
  Как только вы дойдете до первой версии своего продукта, вам, скорее всего, потребуется несколько раз изменить ее, чтобы удовлетворить потребности ваших клиентов. Опять же, множественные ветки и пулл-реквесты резко снижают скорость разработки и не рекомендуются в таких случаях.

• Когда вы работаете в основном со старшими разработчиками.
  Если ваша команда состоит в основном из старших разработчиков, которые работали друг с другом в течение длительного периода времени, вам не нужно вышеупомянутое микроуправление запросами на включение. Вы доверяете своим разработчикам и знаете, что они профессионалы. Позвольте им делать свою работу и не замедляйте их со всей бюрократией потока Git.

Рабочий процесс разработки на основе магистрали

В модели разработки на основе магистралей все разработчики работают в одной ветке с открытым доступом к ней. Часто это просто master ветка. Они коммитят код и запускают его. Это очень просто.

В некоторых случаях они создают недолговечные ветки функций. Как только код в их ветке компилируется и проходит все тесты, они сливают его прямо в master . Это гарантирует, что разработка действительно непрерывна, и не позволяет разработчикам создавать конфликты слияния, которые трудно разрешить.

Давайте посмотрим на рабочий процесс разработки на основе магистралей.

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

Этот стиль работы может быть отличным, когда вы работаете с командой опытных разработчиков программного обеспечения. Это позволяет им быстро и без лишней бюрократии внедрять новые усовершенствования. Это также показывает им, что вы им доверяете, поскольку они могут вводить код прямо в master ветку. Разработчики в этом рабочем процессе очень автономны — они доставляют напрямую и проверяют конечные результаты в рабочем продукте. В этом методе определенно гораздо меньше микроменеджмента и возможностей для офисной политики.

Если, с другой стороны, у вас нет опытной команды или вы по какой-то причине не доверяете им, вам не следует использовать этот метод — вместо этого вы должны выбрать Gitflow. Это избавит вас от ненужных забот.

Плюсы и минусы магистральной разработки

Давайте подробнее рассмотрим обе стороны затрат — самый лучший и самый худший сценарии.

Когда транковая разработка работает лучше всего?

• Когда вы только начинаете.
  Если вы работаете над своим минимально жизнеспособным продуктом, то этот стиль идеально вам подходит. Он предлагает максимальную скорость разработки с минимальными формальностями. Поскольку запросов на вытягивание нет, разработчики могут добавлять новые функции со скоростью света. Только не забудьте нанять опытных программистов.

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

• Когда вы работаете в основном со старшими разработчиками.
  Если ваша команда состоит в основном из старших разработчиков, то вы должны доверять им и позволить им делать свою работу. Этот рабочий процесс дает им необходимую автономию и позволяет им владеть мастерством в своей профессии. Просто дайте им цель (задачи для выполнения) и наблюдайте, как растет ваш продукт.

Когда транковая разработка может вызвать проблемы?

• Когда вы запускаете проект с открытым исходным кодом.
  Если вы работаете с проектом с открытым исходным кодом, лучше использовать Gitflow. Нужен очень строгий контроль над изменениями и нельзя доверять контрибьюторам. Ведь внести свой вклад может каждый. В том числе онлайн-троллей.

• Когда у вас много младших разработчиков.
  Если вы нанимаете в основном младших разработчиков, то лучше жестко контролировать то, что они делают. Строгие пулреквесты помогут им улучшить свои навыки и быстрее найдут потенциальные ошибки.

• Когда вы создали продукт или управляете большими командами.
  Если у вас уже есть успешный продукт или вы управляете большими командами на огромном предприятии, Gitflow может быть лучшей идеей. Вы хотите иметь строгий контроль над тем, что происходит с хорошо зарекомендовавшим себя продуктом стоимостью в миллионы долларов. Вероятно, производительность приложения и возможности загрузки являются наиболее важными вещами. Такая оптимизация требует очень точных изменений.

Используйте правильный инструмент для правильной работы

Как я уже говорил, Git — это всего лишь инструмент. Как и любой другой инструмент, его нужно использовать по назначению.

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

Разработка на основе магистралей дает программистам полную автономию и выражает большую веру в них и их суждения. Доступ к исходному коду бесплатный, поэтому вам действительно нужно доверять своей команде. Это обеспечивает отличную скорость разработки программного обеспечения и сокращает процессы. Эти факторы делают его идеальным при создании новых продуктов или изменении существующего приложения в совершенно новом направлении. Это творит чудеса, если вы работаете в основном с опытными разработчиками.

Тем не менее, если вы работаете с младшими программистами или людьми, которым вы не полностью доверяете, Gitflow — гораздо лучшая альтернатива.

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