Стратегия ветвления Git для небольших частых функций, ориентированных на одну среду

Question

Наш процесс разработки похож на описанный в этом вопросе и требует создания множества мелких функций. Обычно 4-8 функций в день. Все функции должны быть развернуты в одной тестовой среде, поэтому должна быть одна ветвь test.

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

Мы абсолютно новички в Git и общих стратегиях ветвления (таких как git-flow) и пытаемся найти стратегию, которая лучше всего подходит для небольших частых функций.

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

Answer 1

Учитывая, что у вас есть как минимум две основные ветви:

1. production или ветка master, которая будет опубликована
2. test или рабочая веткагде вы тестируете все новые функции

Учитывая ваш подход к разработке всех новых функций непосредственно на test, а затем объединяете эти новые функции с production (объединение test с production),В какой-то момент у вас появятся разработанные вами функции, которые вы не хотите публиковать в production.Затем вы будете вынуждены продолжить работу над своей веткой reset test, иначе у вас останется много нежелательных функций, опубликованных в production.Или вам нужно будет сбросить ветку test и снова перейти с production, чтобы иметь чистую копию для работы.Затем, если многие члены команды работают над веткой test и все объединяют свои изменения с test, каждому члену команды будет сложно отследить функции, над которыми работают другие члены команды, поэтому разрешение конфликтов станет более сложным.для достижения.

Я думаю, что лучшим вариантом будет рассматривать каждую функцию как отдельную ветвь, разветвленную непосредственно от production.Так, например, за день, когда вам нужно 3 новых функции, вы будете переходить с production и создавать: features/one, features/two и features/three.Когда каждая из этих функций готова (в разное время разными членами команды), все они объединяются в test (каждый член команды должен знать только об изменениях, которые он сделал для разрешения конфликтов, потому что он работает надконтролируемая ветвь с внутренними изменениями, которые он внес в проект), а затем демонстрируется клиенту или руководителю группы.Возможно, все функции одобрены, но, возможно, одна из этих функций будет отклонена.С помощью этой стратегии ветвления теперь очень легко отказаться от всех нежелательных функций и опубликовать утвержденные: вам просто нужно объединить утвержденные функции и отказаться от других.

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

В вашем случае, возможно, вы вносите небольшие исправления в проект (возможно, проект является веб-сайтом, и вы просто исправляетеопечатки), вы можете иметь ветку hotfix/quick-fixes (ветвь от production), где вы работаете со всеми этими небольшими изменениями (которые обязательно будут опубликованы), а затем объединить эти изменения с test, чтобы быстро просмотреть ихизменяется или вы просто объединяетесь в production для публикации.

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