Концепции управления исходным кодом - ветвь для объекта, тег для проверки

Question

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

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

Answer 1

Я не слышал о такой вещи. Похоже, чрезмерное использование ветвления для меня. Я думаю, это зависит от того, что мы подразумеваем под словом «особенность». Это вариант использования? Пользовательская история? Вся итерация?

Ветви подразумевают параллельное развитие. Если вы не разрабатываете параллельно, почему ветвь?

Несколько хороших отзывов о SCM от нашего ведущего, Джеффа Этвуда:

1. Эрик Синк
2. Учебник для ветвления и слияния

И, конечно же, книга о красных бобах SVN:

http://svnbook.red -bean.com /

Мне также нравится то, что "Pragmatic Version Control" говорит о ветвлении и тегировании.

Answer 2

Я бы даже пошел дальше и внедрил «ветвь на задачу» , где вы используете ветку для каждой проблемы в вашей системе отслеживания проблем (вы знаете, bugzilla, JIRA и т. Д.).

Это может звучать немного «экстремально», но за ним очень легко следить, если вы используете SCM с поддержкой веток, такой как Git, Mercurial или Plastic (и я склонен к Plastic, конечно: P)

Answer 3

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

Кроме того, существуют определенные критерии размера (по общему признанию, нечеткие). Если у вас есть 10 разработчиков, то, насколько я понимаю, у вас есть только одна команда разработчиков - не имеет значения, всегда ли двое из них «парни из диалогового окна виджетов» или «парни из базы данных». Вам вполне может понадобиться> 1 ветка разработки, если кто-то проводит серьезный рефакторинг, вносит серьезные изменения в API, изменяет ожидаемое поведение, так что многие BVT не будут работать, и т. Д. Но это не ветвь функций.

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

Если вы работаете в Windows, слои и слои ветвей объектов - это находка. Если команда оболочки не может быть продуктивной, потому что команда ядра внесла ошибку, это большая проблема.

Конечно, нужно сделать балансировочный акт. Некоторые крупные организации слишком разветвляются. Когда пройдет несколько месяцев, прежде чем код, благословленный функциональной группой X, перейдет в команду Y, боль от слияния + интеграционное тестирование перевесит стабильность кодовой базы, которую вы пытались получить в первую очередь. (отсюда и фраза «глубина вашего дерева от MAIN обратно пропорциональна вашему здравомыслию») И в каждом случае дерево для версии N должно сужаться по мере приближения к своему выпуску, в конечном итоге сворачиваясь до такой степени, что будут выполняться только проверки непосредственно в стволе этого выпуска включены, и каждая ветвь функции эффективно нацелена на N + 1.

Answer 4

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