Когда следует создавать ветки разработки?

Мы перемещаем команду нашего проекта от использования одной ветки Main / Trunk к нескольким веткам разработки / работы, которые должны регулярно объединяться в Main. Мы основываем наш новый процесс на этой статье и Руководстве по ветвлению TFS (мы используем TFS и Visual Studio 2010).

В настоящее время над проектом работают от 1 до 5 человек. Main должен быть стабильным всегда, потому что мы хотим, чтобы опция выпускалась всякий раз, когда нам нужно. У нас нет фиксированных спринтов - по крайней мере, пока - и сейчас выпускаем каждые 1-2 недели.

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

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

У кого-нибудь есть какое-то руководство по этому поводу?

Мне не нравятся произвольные ветки, то есть исправления Фреда или исправления Гарри. Мне гораздо удобнее с одной (независимой) функцией, одной веткой, которая позволяет нескольким разработчикам работать с одной функцией; но для функции, которая будет объединена только тогда, когда она завершена.

Итак, сейчас вам нужна только ветка «bugfix», но как только вы начнете разработку, вы должны создать ветку для каждой существенной функции. Таким образом, когда они сделаны, они могут быть объединены и выпущены без зависимости от других функциональных возможностей.

Не уверен, насколько хорош TFS при слиянии, но я уверен, что вы узнаете через несколько месяцев :)

Мы не можем обойтись без одной ветки разработки, потому что мы хотим объединиться с Main, пока другие работы завершены.

Похоже, вы уже знаете, что необходимо создать несколько веток разработки. На ум приходят два вероятных сценария:

1. Каждый из пяти разработчиков работает на независимых части проекта (ошибка фиксации) - Убедитесь в том , что отдельная ветка будет создана для каждого разработчика. Это возлагает ответственность и ответственность на каждого разработчика, чтобы убедиться, что их набор изменений не вступает в противоречие с чьей-либо работой. Весьма вероятно, что один из ваших пяти разработчиков допустит ошибку. Если / когда это так, то не имеет смысла для всех остальных быть задержанными.
2. Разнообразные разработки функций - Независимо от количества разработчиков, работающих над определенной функцией / ошибкой, их следует разделять. Примером такого преимущества является то, что все коммиты кода являются частью разрабатываемой функции (ий) - здесь не нужно догадываться.

Подразумеваемая работа веток с DVCS

Мы используем Mercurial, поэтому в окне разработчика для разработчиков есть ветвь подразумеваемой работы. Фиксация всегда выполняется в локальной рабочей области. Когда выполнимая часть работы завершена, она отправляется на основной сервер репо, где она автоматически собирается и тестируется.

Мы почти никогда не создаем явные ветки, но опять же наши спринты никогда не длятся более 1 недели, и для их заполнения требуется не более 1-2 дней.

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

Я использовал как одну ветку на историю, так и одну ветку на релиз (все разработчики регистрируют свои истории в dev, и если какая-либо из них нарушает ветку dev, она нарушается для всех). Я очень рекомендую одну ветку за историю, если вам не нравятся конфликты. Ветвь dev всегда будет стабильной для всех разработчиков, и у разработчика не будет времени ждать работы над частью кода, которую уже сломал другой разработчик. Когда ваша история закончена, весь ваш код находится в вашей ветке. Вы объедините его с dev, но не регистрируетесь и тестируете, в случае возникновения конфликтов вы разрешите его и попросите человека, с которым вы конфликтуете, избегать удаления его кода. Затем объединитесь с dev. Это помогает всем разработчикам работать плавно. Это также зависит от размера компании. Наша компания имеет 200 разработчиков, работающих одновременно на одной кодовой базе, но отдельная ветка для своих рассказов. Как только код объединен с веткой dev, ветвь истории немедленно удаляется. Надеюсь, это поможет. благодаря

Если это основано на git, то вы просто создаете ветку для каждого исправления ошибки, исправляете ошибку в кратчайшие сроки, объединяете ветку исправления ошибки с веткой разработки, а затем вносите изменения в ветку разработки. Рассмотрение запросов на извлечение и слияние должно быть наивысшим приоритетом, потому что чем быстрее вы это сделаете, тем больше шансов, что слияние не вызовет проблем. После объединения эти ветви могут быть удалены.