Каковы преимущества использования ветвления в качестве индивидуального разработчика?

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

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

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

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

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

Долгосрочная разработка

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

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

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

Экспериментальные особенности

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

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

Мой рабочий процесс по настройке сайта выглядит следующим образом:

1. Сделать работоспособную мастер ветку. Сделайте начальный коммит.

2. Оформить заказ на разработку филиала. Ничего не делайте, разработайте функции в качестве тестового буфера для слияния с мастером.

3. Оформить заказ ветка. Закодируйте свою проблему, когда она будет завершена, включите ее в разработку, посмотрите, возникнут ли какие-либо проблемы, конфликты слияний и т. Д. ... исправьте их.

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

   Master
     |
   Develop  - E
   / |  \  \
 A   B   C  D

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

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

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

Рассмотрим следующий сценарий: вы всегда работаете над основной веткой, и у вас есть AwesomeCodeThing ™ в работах, которая оставляет вашу ветку Master в хирургии открытого сердца, и появляется всплывающее окно YugeBug ™, требующее срочного исправления, в противном случае тысячи пользователей будут жаловаться вам на BigProblems ™
. Единственный способ быстро решить вашу проблему в таком сценарии,

1. проверьте ваши предыдущие коммиты,
2. посмотрите, когда был ваш последний стабильный коммит (ругаться необязательно)
3. откат к этому коммиту
4. сделать исправление, подтолкнуть исправление к производству
5. решить все конфликты и проблемы, которые у вас сейчас есть, пытаясь вернуться в статус AwesomeCodeThing ™
6. сдавайся, плачь и начинай работать заново (необязательно)

Если вы используете филиалы:

1. Мастер проверки
2. создать ветку UrgentFix ™ и исправить вещи
3. потяните UrgentFix ™ в мастер
4. подтолкнуть к производству
5. Объединить мастер в развитие
6. Объединить развиваться в AwesomeCodeThing ™
7. возьмите пиво и продолжайте работать.

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

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

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

Что касается реального процесса, я считаю, что Git Flow работает хорошо. Шпаргалка Даниэля Куммера ( Git Flow ) - отличный ресурс, на него стоит посмотреть, даже если вы не используете Git.

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

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

Однако, если у меня возникнут какие-либо сомнения относительно изменений, которые я внесу, я буду выполнять ветвление и только PR / слияние только после того, как ветвь будет работать, как ожидается, и в целом будет полностью протестирована. Таким образом, если я обнаружу проблему, для которой откат является наилучшим вариантом действий, то это один коммит вместо целой серии (я никогда не могу вспомнить синтаксис для отката серии коммитов, но один прост).