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

После многих лет жизни в одиночестве, научившись самостоятельно создавать компьютерные программы, вы наконец-то приступаете к работе в команде. Ура! Собравшись со своими товарищами по команде и разбив все задачи, которые вам нужно выполнить, вы, наконец, решаете, что лучше всего, если ваша команда будет использовать систему контроля версий для управления сотрудничеством между вами и всеми вашими товарищами по команде. Потому что, в конце концов, система контроля версий - это система, которая фиксирует изменения в файле или наборе файлов с течением времени, чтобы вы могли позже вызвать определенные версии ». (Скотт Чакон, 2016).

Некоторое время спустя вы и ваша команда решили использовать git version control, чтобы помочь вам в разработке программного обеспечения. Немного о git: Git считает свои данные скорее снимками миниатюрной файловой системы. Каждый раз, когда пользователь совершает коммит, Git делает снимок того, как все файлы выглядят в данный момент, а затем сохраняет ссылку на этот снимок. Если файлы не изменились, Git не будет сохранять эти файлы снова, они просто свяжут файлы с предыдущими идентичными файлами, которые он уже сохранил (https://git-scm.com).

Однако проблема все еще существует. У вашей команды нет рабочего процесса! Все нажимают на основную ветку, что вызывает множество конфликтов слияния и затрудняет отслеживание кодов. Вы начинаете задаваться вопросом, есть ли лучший способ управлять git-потоком вашей команды? Как и почему нужно следовать существующему git-flow? Есть ли лучшая практика?

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

Это одно из первых предложений о том, каким должен быть поток Gitlab. Он предлагает masterbranch и отдельную developbranch, а также вспомогательные ветви для функций, выпусков и исправлений. Разработка происходит в ветке develop, переходит в ветвь выпуска и, наконец, объединяется с веткой master.

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

Если честно, такой поток тоже выглядит чересчур избыточным. В реальном мире разработчики обычно останавливаются только на develop ветви. Следовательно, ветвь master и веткаhotfix почти не используются. Некоторые разработчики также совершают ошибки, например, объединяют изменения только в master, а не в ветку develop. Причина этих ошибок в том, что поток Git слишком сложен для большинства случаев использования. Например, многие проекты выпускают релизы, но не требуют исправлений.

Это некий альтернативный поток Git, который я создал, чтобы исправить некоторые из проблем, упомянутых ранее.

Как это работает?

  • Сначала создайте ветвь по умолчанию master в вашем репозитории. Вы должны сделать его защищенным, чтобы разработчики не могли случайно отправить свою работу в основную ветку. master ветка может быть объединена только из ветки development. Themasterbranch содержит тег, чтобы определить, какая это версия.
  • Ветвь development извлекается из основной ветки. Эта ветка тоже защищена. Разработчики могут сливаться только в эту ветку. Однако есть 2 способа присоединиться к этой ветке: task веток и hotfix веток.
  • Существует много task ветвей, и это не должно быть связано с отдельными функциями. Это должно быть как задача. Например, ветвь «внешний интерфейс страницы входа» должна быть отделена от ветки «внутренняя часть страницы входа». Вы должны объединять task веток с development веткой только в том случае, если она прошла все испытания. И перед объединением не забудьте вытащить все из ветки development. Возможно, некоторые из ваших коллег уже что-то отправили в веткуdevelopment.
  • Ветви hotfix следует использовать только в том случае, если ваша development ветка содержит незначительные ошибки из нескольких task веток. Если эти ошибки может сделать всего 1 человек, это следует сделать в ветке hotfix.

Преимущества

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

Недостатки

  • Это может стать сложным, когда нужно поддерживать несколько версий в продакшене.
  • История Git становится нечитаемой

Использованная литература:

  1. Веб-сайт Gitlab: https://docs.gitlab.com/ee/workflow/gitlab_flow.html
  2. Канон потока: https://flowcanon.com/software/choosing-the-best-git-branching-strategy-for-your-team/