Филиалы служат многим полезным целям, но для этого обсуждения я собираюсь разделить их на две категории:
- Ветки исправлений объединяют ряд слабо связанных исправлений и улучшений.
- Ветви объектов , или ветки тем, изолируют работу над объектом, пока он не будет готов к объединению.
Чтобы придумать приличную стратегию ветвления, нужно посмотреть на проделанную работу и понять, где эти изменения должны жить. На мой взгляд, похоже, что ваша работа по локализации независима (изменения не зависят друг от друга) и стабильна (изменения не нарушают сборку), что делает ее главным кандидатом на ветку исправлений.
С другой стороны, это звучит так, будто работа по скинингу больше напоминает функцию; выполняемая работа тесно связана и, возможно, нестабильна. В результате я хотел бы рассмотреть возможность использования ветви функций.
Позвольте мне сделать вид, что я прав в приведенной выше оценке, и наметить стратегию для вас:
Решение: перебазировать ветку исправления ошибок
Это решение является оптимальным при условии соблюдения следующих условий:
Перебазирование возможно и разрешено. Если над веткой работает только один разработчик, это разрешено по умолчанию. Однако, если есть несколько разработчиков, может быть опасно использовать перебазирование, если вы не можете гарантировать, что перебазирование всегда будет тривиальным.
Ветка исправлений остается "чистой" как можно чаще. Сайт должен быть собран из любой точки ветки исправления ошибок. Если разработка слишком нестабильна, чтобы допустить это, это не очень хорошее решение.
Ветвь исправления ошибок не зависит от ветви функций. Если между двумя усилиями существует большая связь, то перебазирование будет болезненным, и этого решения следует избегать.
Если вы можете выполнить все эти требования, то это может быть очень чистый и выгодный сценарий. Несемантические слияния (т. Е. Те, что были сделаны только для обновления к сегодняшней работе) исключены, а история коммитов предельно ясна. Поскольку ветвь исправления стабильна, ее можно использовать в качестве рута для других функций.
Наконец, когда придет время объединить тему в ветку с исправлениями ошибок, это произойдет без особых усилий в качестве ускоренной перемотки вперед. В этом случае мне нравится отключать ускоренную пересылку, поэтому слияние и ветвление остаются в истории фиксации, чтобы предоставить свидетельство разработанной функции.
Проблема: переназначение невозможно / разрешено
Если над веткой работает несколько разработчиков, и невозможно гарантировать, что для перебазирования не потребуется ручное объединение, то перебазирование опасно.
Чтобы избежать этой проблемы, вам следует рассмотреть возможность использования веток меньшей области видимости; вместо ветки локализации используйте ветку темы "localize personal settings" и ветку исправления ошибок "localization plumbing". Мотивация заключается в том, чтобы соответствовать условиям решения, описанного выше: небольшие ветки могут быть обработаны одним разработчиком, небольшие ветки, как правило, легче перебазировать, а небольшие функции могут быть завершены и предоставлены быстрее, чем большие.
Может показаться нелогичным, что введение большего количества веток упростит вашу разработку. Однако это аналогично рефакторингу одной функции двойного назначения в две функции одного назначения.
Проблема: ветвь исправления не чистая, или зависит от ветви функции
Решение этой проблемы такое же, как и в предыдущем: используйте больше веток. Если есть зависимость, тогда вы должны спросить себя, почему это так: должны ли мы фиксировать ветку функциональности вместо ветви исправления ошибок? Неужели ветка исправления пытается охватить слишком много?
Ветви должны иметь четкое назначение и продолжительность жизни. Если ветвь начинает преследовать несколько целей, преимущества использования контроля версий уменьшаются. Лучше иметь две или три тонко настроенных ветви, чем одну нечеткую.
В сторону: почему повторное слияние плохо
Повторное слияние, вероятно, произойдет по умолчанию.Каждая ветвь хранится отдельно, и слияния используются для обновления одного с прогрессом, который происходит в другом.Нет необходимости изолировать работу, поскольку она будет регулярно передаваться.
Проблемы, связанные с повторным объединением, делают эту альтернативу несостоятельной.История будет загрязнена слияниями, которые не имеют смысловой ценности.Повторное объединение также заставит разработчиков в одной ветке внимательно следить за изменениями в другой ветви, исключая возможность использовать его в качестве корня для других функций.
Если повторное объединение кажется единственной возможностью, вы можетехочу рассмотреть возможность использования только одной ветви и покончить с этим.Вполне возможно, что текущая разработка настолько переплетена, что наличие одной ветви прямо сейчас имеет больше смысла.Когда все уляжется, станет возможным разделить их снова, если это покажется разумным.