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

117

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

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

flatterino
источник
14
Извините, я признаю, что я не очень опытен в модели StackExchange, но должен ли я понимать, что «лучшие практики» или любой другой вопрос, который не имеет ни одного детерминированного ответа, осуждается, или даже нет разрешено обсуждать? Я вижу множество основанных на мнении примеров предположительно правильных вопросов даже в «связанном» разделе этого вопроса, таких как softwareengineering.stackexchange.com/questions/286928 или softwareengineering.stackexchange.com/questions/132730
flatterino
8
Хотя я согласен с Мэн, что этот вопрос не является точным дубликатом (различия в области значительны), но у двойного целевого вопроса, связанного с мошенничеством, действительно есть ответы на интересующую вас тему - есть ли что-то такое? ответы не охватывают то, что вы хотите услышать больше?
JRH
4
Я думал, что, хотя этот вопрос охватывает эту тему, он делает это тангенциально (пользователь задает 3 разных вопроса, связанных с различными аспектами ветвления), и фактически сам вопрос был закрыт из-за того, что он «слишком широк» по этой самой причине. Я надеялся начать обсуждение этой очень специфической особенности VCS в этом аналогичном контексте. Чтобы ответить на ваш вопрос, здесь уже упоминалось несколько его аспектов (в ответах и ​​комментариях к этим ответам), которые не упоминаются в ответах на вопрос, на который вы ссылались. Спасибо всем за ваш вклад.
flatterino
3
Дэн, опять же ... вопрос, который вы связали, задает вопрос: «Как единственный разработчик, какими функциями Git или GitHub я мог бы воспользоваться, что принесло бы мне пользу прямо сейчас?». Возможным ответом на этот вопрос, среди прочего, может быть «ветвление». Это не будет ответом на мой вопрос. Кроме того, он был закрыт как слишком широкий по той же причине. Пожалуйста, прочтите объяснение в верхней части моего вопроса. Я должен был отредактировать свой пост 3 раза сейчас ...
flatterino

Ответы:

199

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

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

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

Себастьян Редл
источник
1
Именно так. Группы также не должны использовать ветки - я работал на команды, которые этого не делали. Конечно, это было в основном из-за незнакомости с git, и все эти команды научились использовать ветки, так как возникали проблемы с их неиспользованием, но эти проблемы также будут относиться и к соло-разработчикам.
KRyan
42

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

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

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

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

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

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

Пэдди
источник
16

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

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

  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. возьмите пиво и продолжайте работать.
Tschallacka
источник
13
Получение пива перед продолжением не является обязательным.
JamesB
4
@JamesB Получение пива перед стартом не является обязательным :)
Крис Cirefice
4

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

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

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

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

Эндрю Колдер
источник
2

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

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

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

RmxPatrick
источник