Вы чувствуете себя комфортно, объединяя код?

Question

Этим утром я прочитал два мнения о рефакторинге.

• Мнение 1 (Страница отсутствует)
• Мнение 2 (Страница отсутствует)

Они рекомендуют разветвлять (и впоследствии объединять) код для:

1. Содержите багажник в чистоте.
2. Разрешить разработчику уйти от рискованных изменений.

По моему опыту (особенно с Borland's StarTeam), слияние является нетривиальной операцией. И по этой причине я делаю ветки только тогда, когда должен (т.е. когда хочу заморозить кандидата на релиз).

Теоретически ветвление имеет смысл, но механика слияния делает его очень рискованной операцией.

Мои вопросы:

• Чувствуете ли вы себя комфортно, объединяя код?
• Вы передаете код по причинам, отличным от замораживания релиза? кандидат?

Answer 1

Ветвление может быть болезненным, но не должно быть.

Это то, что git-подобные проекты (mercurial, bazar) рассказывают нам о CVS и SVN. На git и mercurial ветвление легко. В SVN это легко, но с большими проектами это может быть немного сложным (из-за времени, затрачиваемого на процесс ветвления / слияния, который может быть очень длительным - по сравнению с некоторыми другими, такими как git и mercurial) - и трудным, если нет очевидные конфликты). Это не помогает пользователям, которые часто не разветвляются, иметь уверенность в разветвлении. Многие пользователи, не подозревающие о мощном использовании ветвления, просто держат его подальше, чтобы не добавлять новые проблемы в свои проекты, позволяя страху неизвестного сделать их далекими от эффективности.

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

Несколько веских причин для филиалов:

• работает над определенной функцией параллельно с другими людьми (или одновременно работает над другими функциями, если вы один в проекте);
• с несколькими фирменными версиями приложения;
• с параллельными версиями одного и того же приложения - например, параллельные методы, разработанные в одно и то же время частью команды, чтобы посмотреть, что работает лучше;
• имея ресурсы приложения, изменяемые в конкретной ветви художника / дизайнера (например, в играх), где приложение "стабильно", тогда как другие ветви и ствол используются для добавления и отладки функций;
• [добавить сюда полезные названия]

Answer 2

Некоторые свободные руководящие принципы:

• Ветвление поздно и только когда вам нужно
• Слияние рано и часто
• Найдите подходящего человека для слияния, либо тот, кто внес изменения, либо тот, кто написал оригинальную версию, являются лучшими

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

Ваше отношение к ветвлению должно, вероятно, отличаться между распределенными проектами с открытым исходным кодом (например, в Git) и проектами развития вашей компании (возможно, работающими в SVN). Для распределенных проектов вы должны поощрять ветвление, чтобы максимизировать инновации и эксперименты, для последнего варианта вам потребуется более жесткий контроль и диктовать правила регистрации для каждой строки кода, которые определяют, когда ветвление должно / не должно происходить, в основном для «защиты» код.

Вот руководство по ветвлению:
http://www.vance.com/steve/perforce/Branching_Strategies.html

Вот краткое руководство с лучшими практиками высокого уровня:
https://www.perforce.com/sites/default/files/pdf/high-level-perforce-best-practices.pdf

Answer 3

Используя SVN, я обнаружил, что ветвление относительно безболезненно. Особенно, если вы периодически объединяете ствол с вашей веткой, чтобы не дать ему слишком расстроиться.

Answer 4

Ветвление тривиально. Слияния нет. По этой причине мы редко что-либо разветвляем.

Answer 5

Мы используем SVN. Это займет у нас около 5 минут, чтобы перейти код. Это тривиально по сравнению с количеством боли, которое спасает нас от путаницы в туловище.

Answer 6

Работа в кодовой базе миллионов строк кода с сотнями разработчиков ветвлений - обычное явление. Срок службы филиала варьируется в зависимости от объема выполняемой работы.

Для небольшого исправления:

• дизайнер делает боковую ветвь от основного потока
• вносит изменения
• Тесты
• Отзывы
• объединяет накопленные изменения из основного потока в боковую ветвь
• повторяет один или несколько предыдущих шагов
• сливается с основным потоком

Для команды из нескольких человек:

• команда делает функцию боковой ветки от основного потока
• отдельный член команды работает на боковой ветви объекта, как в подходе "small fix", и сливается с боковой веткой объекта.
• простое число боковых веток периодически объединяет накопленные изменения из основного потока в боковое отделение функции. С небольшими инкрементными слияниями основного потока и боковой ветки гораздо проще справиться.
• когда функция работает, сделайте окончательное объединение из основного потока в боковую ветвь функции
• объединение боковой ветви функции с основным потоком

Для выпуска программного обеспечения клиента:

• сделать ветку релиза
• доставлять исправления по мере необходимости для выпуска ветки
• исправления распространяются в / из основного потока по мере необходимости

Потоки релизов клиентов могут быть очень дорогими для поддержки. Требуются ресурсы тестирования - люди и оборудование. Через год или два знания разработчиков по конкретным потокам начинают устаревать по мере продвижения основного потока.

Можете ли вы представить, сколько должно стоить Microsoft для одновременной поддержки XP, Vista и Windows 7? Подумайте об испытательных стендах, администрировании, документации, обслуживании клиентов и, наконец, командах разработчиков.

Золотое правило: Никогда не нарушайте основной поток, так как вы можете остановить большое количество разработчиков. $$$

Answer 7

Проблема ветвления заключается в том, что я использую систему управления распределенной версией (в моем случае Git, но есть также Mercurial и Bazaar), где создание ветки тривиально.

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

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

Answer 8

Я использую Subversion и считаю ветвление очень простым и легким. Итак, чтобы ответить на вопрос 1. Да.

Причина ветвления может сильно различаться. Я разветвляюсь, если чувствую, что должен. Довольно сложно изложить правила и причины для всех возможностей.

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

Answer 9

Я работал над проектом с использованием SVN и TFS, и само по себе ветвление - это действительно простая вещь.

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

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

Сказав вышесказанное, я бы сказал, что ветвление - это мощная и полезная практика, которую следует учитывать при разработке.

Answer 10

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