Git Workflows для профессионалов: хорошее руководство по Git

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

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

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

Сотрудничество

С точки зрения процесса Git совместная работа часто связана с разветвленными рабочими процессами. Заранее продумывая, как вы будете переплетать деревья коммитов, вы сведете к минимуму ошибки интеграции и поддержите свою стратегию управления релизами.

Филиал интеграции

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

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

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

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

Тематические ветки

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

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

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

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

НЕ ИСПОЛЬЗУЙТЕ тематические ветки в общедоступных репозиториях, вы вызовете множество конфликтов для тех, кто синхронизировал свои локальные ветки с тематическими ветками, дерево коммитов которых было переписано заново.

Вилка

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

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

Шаблон рабочего процесса fork дает командам собственное пространство для работы любым способом, к которому они привыкли, с единой точкой интеграции между двумя репозиториями — запросом на вытягивание. Чрезмерное общение обязательно в описании запроса на извлечение. У команд были отдельные потоки связи до того, как был выпущен запрос на включение, и выделение уже принятых решений ускорит процесс проверки.

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

Убедитесь, что вы используете инструмент, который упрощает создание ответвлений и запросов на вытягивание, чтобы воспользоваться преимуществами этого шаблона. Эти инструменты не ограничиваются Github: другие популярные варианты — Bitbucket и GitlLab. Но есть довольно много других сервисов хостинга рабочих процессов Git, которые будут иметь эти функции (или аналогичные). Выберите, какая услуга лучше всего подходит для вас.

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

Клон

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

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

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

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

Управление выпуском

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

Окружающая среда Филиалы

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

Команды, работающие с этими процессами, часто имеют среды приложений, настроенные для каждого этапа конвейера, например «QA», «Staging» и «Production». В этих случаях имеется инфраструктура для поддержки персонала, ответственного за одобрение функции или вклада в свою часть того, что значит быть готовым к производству (например, исследовательское тестирование, контроль качества, приемочное тестирование), прежде чем передать ее следующему человеку. сцена. Это дает им собственное место для развертывания, тестирования и оценки их требований, а рабочий процесс Git записывает его прохождение через туннель выхода.

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

НЕ используйте этот паттерн, не рассмотрев сначала долгосрочные преимущества других паттернов.

Ветки выпуска

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

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

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

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

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

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

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

НЕ ИСПОЛЬЗУЙТЕ ветки релиза с несколькими командами, работающими над одним и тем же репозиторием. Несмотря на то, что ветки релиза недолговечны, если окончательная проверка занимает слишком много времени, это задерживает другую команду от релиза. Команда, поддерживающая ветку релиза другой команды, может привести к ошибкам и задержкам для обеих команд. Посмотрите на приведенный ниже шаблон выпуска с отметкой времени, который лучше подходит для большего числа и групп участников.

Релизы с отметкой времени

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

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

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

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

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

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

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

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

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

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

Ветвь версии

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

Репозиторий, использующий ветки версий, будет иметь одну ветку для каждой дополнительной версии приложения. Основные, второстепенные версии и версии исправлений описаны в документации Semantic Versioning. Ветви версий обычно следуют соглашению об именах, включающему слово «стабильная» и удаляющему номер исправления из версии приложения: например 2-3-stable , чтобы сделать их назначение и надежность очевидными для конечных пользователей.

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

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

НЕ используйте ветки версий, если вы не поддерживаете более одной версии вашего репозитория.

Резюме

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

Шаблон в этом руководстве может помочь вам вооружиться некоторой предусмотрительностью в адаптации вашей распределенной системы управления версиями, чтобы она работала на вас. Если вы хотите прочитать о рабочих процессах Git, обязательно ознакомьтесь с Gitflow, Github Flow и, самое главное, с замечательной документацией по git-scm!