[Git] Бранч-стратегии при разработке в Git
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Если каждый член команды будет создавать ветки в Git так, как хочет, это обязательно приведет к хаосу и несогласованности. Чтобы избежать этого, лучше сформулировать и принять соответствующую бранч-стратегию — так вы сможете больше времени уделять разработке, а не управлению версиями. Нужно принять тот факт, что стратегия ветвления — важный рабочий инструмент.
Три подхода
Вы можете использовать одну из этих популярных методик или же взять их как основу для создания своей.
GitHub Flow. Стратегией пользуются в команде сервиса GitHub. Главные требования звучат так:
- в коде в мастер-ветке не допускаются ошибки, и он должен быть готов к развертыванию в любой момент;
- чтобы начать разрабатывать новую функцию, необходимо создать feature-ветку в master-ветке и дать ей очевидное для всех имя. Когда работа будет готова, ее нужно смерджить в master-ветку через pull request;
- после мерджа изменений их нужно сразу же развернуть на сервере.
Этот подход обычно используют для продуктов с одной версией, которая обновляется не очень часто. Например, веб-сайтов. Из плюсов — разработчикам при таком подходе проще понимать и организовывать свою работу. Главный минус — если ваш проект достаточно сложный и обновляется часто, лучше использовать другую стратегию.
GitFlow. Сразу стоит сказать, что эта стратегия дискуссионная. О ней есть много как положительных, так и отрицательных отзывов.
Суть в следующем. Есть два типа постоянных веток: master-ветка, чтобы понимать, как выглядит последняя актуальная версия, и development-ветка, где ведется разработка. От нее идут три вида временных веток.
- Feature, для добавления новых возможностей. После завершения работы нужно создать pull request в development-ветку.
- Release, для работы над новыми версиями. Важно добавить в название номер версии, это поможет не запутаться и отследить изменения.
- Hotfix, для быстрого исправления багов.
Этот подход считается одним из оптимальных для проектов, где постоянно разрабатывается несколько версий для разных платформ.
В 2010 году вышел текст голландского программиста Винсента Дриссена «A successful Git branching model», в которой он впервые рассказал о GitFlow. Статья стала довольно популярной, появился русский перевод, а методика была взята на вооружение во многих командах.
В 2020 году американский программист Джордж Стокер выпустил статью «Please stop recommending Git Flow», где он раскритиковал метод, как устаревший и неэффективный в современных реалиях. Дриссен в ответ дополнил свой текст 2010 года дисклеймером, в котором признал, что его метод не панацея, а только один из вариантов организации работы.
Forking Workflow. Здесь подход такой: существует оригинальный репозиторий для мерджа всех изменений и его копия, в которой работает другой разработчик. Подход очень близок к идеологии open source, его цель — использовать все преимущества open-source-сообщества в рамках проекта. При этом большая часть рабочего процесса в части ветвления копирует GitFlow. Feature-ветки здесь будут мерджиться с локальными репозиториями разработчиков. Таким образом, разработка становится гибкой даже для очень больших команд с подрядчиками.
Среди тех, кто использует такой подход — Linux. Вы можете предложить свои варианты изменения кода даже для ядра системы. И этот подход, судя по всему, эффективно работает.
Общие моменты
Какую бы концепцию вы не выбрали, есть основные моменты, которых лучше придерживаться. Вот, например, правила Microsoft:
- не усложняйте вашу бранч-стратегию;
- используйте feature-ветки для всех обновлений и исправления ошибок;
- объединяйте feature-ветки в основные с помощью pull requests;
- поддерживайте высокое качество и актуальность основной ветки.
Стратегия, основанная на этих идеях приведет к тому, что ваша команда будет работать с логичными и простыми для понимания версиями.
Вот еще несколько полезных принципов.
Называйте все просто и очевидно
Это поможет всем членам команды правильно понимать, кто над чем работает. Также допустимо включить в название ветки дополнительную информацию, например, имя создателя. Это тот случай, когда не нужно придумывать что-то оригинальное. Названия веток типа «пользователи», «багфикс», «feature», «hotfix» — то что надо. Для веток, работа в которых затягивается, используйте отдельные специальные флаги. Это позволит команде сразу понимать о чем идет речь и всегда держать в голове эти задачи как долгосрочные.
Слияние веток только через pull request
Механизм pull request зарекомендовал себя как логичный и хорошо придуманный. Так как этот процесс требует времени, вы должны принять внутри команды, что и в какие сроки ожидается от всех участников pull request. Распределите обязанности ревьюеров и расскажите об этом команде через внутреннюю базу знаний.
Вот немного конкретных советов:
- согласно исследованию Microsoft, оптимальное число ревьюеров — двое;
- если в вашей команде уже сформировались принципы рецензирования кода, придерживайтесь их и старайтесь не ломать;
- pull request работает намного лучше, когда обязанность ревьюить код регулярно возникает у большего числа членов команды;
- оставляйте достаточно подробные описания к своей работе, чтобы ревьюеры могли быстро понять контекст.
Настройте branch policies
Потратить время на политики ветвления стоит по нескольким причинам:
- так вы сможете изолировать текущую работу от завершенной в рамках главной ветки;
- внесете разумные ограничения, определив кто и какие изменения может вносить в конкретные ветки;
- быстро распространите эффективные методы работы.
Два основных правила, исходя из которых следует настраивать политики:
- ревьюеры в pull request добавляются автоматически, в момент его создания. Вы можете сначала определить их список, а затем редактировать по ходу работы;
- для выполнения pull request требуется успешная сборка. Код, влитый в основную ветку, должен собираться чисто.
Но самый главный принцип при создании своей бранч-стратегии такой: нужно продумать ее так, чтобы у команды не возникало вопросов по поводу смысла того или иного действия. Тогда в вашем проекте каждый день будет результативным.
Блог ITGLOBAL.COM — Managed IT, частные облака, IaaS, услуги ИБ для бизнеса:
- Главные тенденции ИТ-индустрии в 2021 году по версии Gartner
- 6 проблем при внедрении DevOps и методы их решения. Главное из отчета Microsoft
- Боли стартапов: как правильно развивать ИТ-инфраструктуру
===========
Источник:
habr.com
===========
Похожие новости:
- Выпуск распределенной системы управления исходными текстами Git 2.30
- [JavaScript, Программирование, Дизайн мобильных приложений, TypeScript] Автоматизируем локализацию макетов в Figma
- [Python, Qt] Кастомизация календаря на PyQt5
- [Анализ и проектирование систем, ERP-системы, Управление разработкой, DevOps] Как сделать хорошую интеграцию? Часть 1
- [Разработка веб-сайтов] 5 распространенных ошибок разработчиков, влияющих на время загрузки страницы (перевод)
- [Поисковые технологии, История IT, IT-компании] История AltaVista и сохранение прошлого Интернета (перевод)
- [Разработка под iOS, Разработка мобильных приложений, Разработка под Android, Тестирование мобильных приложений] 3 видео для мобильного разработчика
- [Программирование, Разработка мобильных приложений, Разработка под Android, Развитие стартапа, Софт] Бизнес-идея для программистов. Совершенно незанятая ниша на рынке программ
- [Open source, JavaScript, Голосовые интерфейсы] Навыки для виртуальных ассистентов на веб-технологиях
- [Работа с видео, Разработка игр, Монетизация игр, Игры и игровые приставки] Какие ролики об играх мы сделали в 2020-м
Теги для поиска: #_git, #_itglobal.com, #_git, #_metodiki (методики), #_razrabotka (разработка), #_vetvlenie (ветвление), #_blog_kompanii_itglobal.com (
Блог компании ITGLOBAL.COM
), #_git
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 22:42
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Если каждый член команды будет создавать ветки в Git так, как хочет, это обязательно приведет к хаосу и несогласованности. Чтобы избежать этого, лучше сформулировать и принять соответствующую бранч-стратегию — так вы сможете больше времени уделять разработке, а не управлению версиями. Нужно принять тот факт, что стратегия ветвления — важный рабочий инструмент.  Три подхода Вы можете использовать одну из этих популярных методик или же взять их как основу для создания своей. GitHub Flow. Стратегией пользуются в команде сервиса GitHub. Главные требования звучат так:
Этот подход обычно используют для продуктов с одной версией, которая обновляется не очень часто. Например, веб-сайтов. Из плюсов — разработчикам при таком подходе проще понимать и организовывать свою работу. Главный минус — если ваш проект достаточно сложный и обновляется часто, лучше использовать другую стратегию. GitFlow. Сразу стоит сказать, что эта стратегия дискуссионная. О ней есть много как положительных, так и отрицательных отзывов. Суть в следующем. Есть два типа постоянных веток: master-ветка, чтобы понимать, как выглядит последняя актуальная версия, и development-ветка, где ведется разработка. От нее идут три вида временных веток.
Этот подход считается одним из оптимальных для проектов, где постоянно разрабатывается несколько версий для разных платформ. В 2010 году вышел текст голландского программиста Винсента Дриссена «A successful Git branching model», в которой он впервые рассказал о GitFlow. Статья стала довольно популярной, появился русский перевод, а методика была взята на вооружение во многих командах. В 2020 году американский программист Джордж Стокер выпустил статью «Please stop recommending Git Flow», где он раскритиковал метод, как устаревший и неэффективный в современных реалиях. Дриссен в ответ дополнил свой текст 2010 года дисклеймером, в котором признал, что его метод не панацея, а только один из вариантов организации работы. Forking Workflow. Здесь подход такой: существует оригинальный репозиторий для мерджа всех изменений и его копия, в которой работает другой разработчик. Подход очень близок к идеологии open source, его цель — использовать все преимущества open-source-сообщества в рамках проекта. При этом большая часть рабочего процесса в части ветвления копирует GitFlow. Feature-ветки здесь будут мерджиться с локальными репозиториями разработчиков. Таким образом, разработка становится гибкой даже для очень больших команд с подрядчиками. Среди тех, кто использует такой подход — Linux. Вы можете предложить свои варианты изменения кода даже для ядра системы. И этот подход, судя по всему, эффективно работает. Общие моменты Какую бы концепцию вы не выбрали, есть основные моменты, которых лучше придерживаться. Вот, например, правила Microsoft:
Стратегия, основанная на этих идеях приведет к тому, что ваша команда будет работать с логичными и простыми для понимания версиями. Вот еще несколько полезных принципов. Называйте все просто и очевидно Это поможет всем членам команды правильно понимать, кто над чем работает. Также допустимо включить в название ветки дополнительную информацию, например, имя создателя. Это тот случай, когда не нужно придумывать что-то оригинальное. Названия веток типа «пользователи», «багфикс», «feature», «hotfix» — то что надо. Для веток, работа в которых затягивается, используйте отдельные специальные флаги. Это позволит команде сразу понимать о чем идет речь и всегда держать в голове эти задачи как долгосрочные. Слияние веток только через pull request Механизм pull request зарекомендовал себя как логичный и хорошо придуманный. Так как этот процесс требует времени, вы должны принять внутри команды, что и в какие сроки ожидается от всех участников pull request. Распределите обязанности ревьюеров и расскажите об этом команде через внутреннюю базу знаний. Вот немного конкретных советов:
Настройте branch policies Потратить время на политики ветвления стоит по нескольким причинам:
Два основных правила, исходя из которых следует настраивать политики:
Но самый главный принцип при создании своей бранч-стратегии такой: нужно продумать ее так, чтобы у команды не возникало вопросов по поводу смысла того или иного действия. Тогда в вашем проекте каждый день будет результативным. Блог ITGLOBAL.COM — Managed IT, частные облака, IaaS, услуги ИБ для бизнеса:
=========== Источник: habr.com =========== Похожие новости:
Блог компании ITGLOBAL.COM ), #_git |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 22:42
Часовой пояс: UTC + 5