Везде, где я ищу правильный способ использования GIT в команде, нас всегда называют git-flow.
Мы начали использовать эту схему как нашу библию в начале:
Прошло время, и мы, наконец, обнаружили, что сохранение master в качестве стабильной ветки с помеченными коммитами было пустой тратой времени.
Зачем вам ОТМЕЧАТЬ свою стабильную фиксацию, а затем НАЖАТЬ для master той же версии, которую вы уже пометили? Тег существует, вы можете вернуться к этой фиксации в любое время. Почему я должен сохранять эту ветку только для того, чтобы содержать только теги?
Вот поток, который мы используем, и он работает как шарм:
Мастер: Это на самом деле наша ветка разработки
Релиз: мы создаем ветку релиза, чтобы выполнить наш последний тестовый пример релиза, а затем добавляем исправление, если это необходимо.
Функция: мы переходим от мастера, чтобы создать функцию, а затем отправляем запрос на включение в мастер.
На самом деле это то же самое, что и git-flow, только без ветки, содержащей стабильную версию.
Еще одним преимуществом этого является то, что master является ветвью develop. Поэтому, когда в проекте появляется новый товарищ по команде, он может начать с клонирования проекта, и его master уже соответствует фактической разработке.
На изображении:
Мой вопрос: зачем вам использовать оригинальный git-flow с 5 ветвями, если вы можете управлять только 4 ветвями с одинаковым результатом?
developветку, аmasterдля разработки и поддерживают ветки для долгосрочного обслуживания нескольких версий параллельно. - person Maggyero schedule 25.09.2019