Git

Git делает разработку программного обеспечения, ну, проще

Три совета, чтобы Git вписался в ваш agile рабочий процесс (и наоборот)

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

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

Совет 1: начните думать о задачах как о ветвях Git

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

 

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

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

Совет 2: Несколько веток могут быть проверены индивидуально, поэтому воспользуйтесь преимуществом

Когда ветки считаются готовыми и готовыми к проверке кода, Git играет еще одну ключевую роль в процессе agile разработки: тестировании. Успешные agile команды практикуют проверки кода и настраивают автоматизированные тесты (непрерывная интеграция или непрерывная разработка). Чтобы помочь с проверкой кода и тестированием, разработчики могут легко уведомить остальную часть своей команды, что работа ветви готова к проверке и что ее необходимо проверить с помощью запроса на извлечение. Проще говоря, запрос на извлечение - это способ попросить другого разработчика объединить одну из ваших веток с основной веткой и подготовить ее к тестированию.

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

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

Совет 3: Git обеспечивает прозрачность и качество для agile разработки

Git / agile рассказывает об эффективности, тестировании, автоматизации и общей гибкости. После того как вы слили ветку с главной веткой, ваш agile рабочий процесс завершен. Аналогично, слияние кода с помощью запросов на извлечение означает, что когда код завершен, у вас есть документация, позволяющая уверенно знать, что ваша работа «зеленая», и то что другие члены команды подписали код и что он готов к выпуску релиза. Это позволяет agile командам двигаться со скоростью и уверенностью в частом выпуске релизов - признак отличной agile команды.

По материалам Agile Coach "Git"