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

Question

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

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

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

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

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

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

Мои вопросы:

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

Answer 1

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

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

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

Ваше отношение к ветвлению, вероятно, должно различаться в распределенных проектах с открытым исходным кодом (например, в 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 2

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

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

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

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

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

Answer 3

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

Answer 4

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

Answer 5

Мы используем svn.На ответвление кода у нас уходит всего около 5 минут.Это тривиально по сравнению с тем количеством боли, от которой это избавляет нас от порчи туловища.

Answer 6

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

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

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

Для командной функции из нескольких человек:

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

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

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

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

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

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

Answer 7

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

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

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

Answer 8

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

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

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

Answer 9

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

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

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

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

Answer 10

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

Answer 11

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

Мы также разветвляем релизы.

Ветвление и слияние хорошо сработали для нас.Конечно, бывают моменты, когда нам приходится сидеть и думать о том, как все сочетается друг с другом, но обычно svn отлично справляется с объединением всего.

Answer 12

Я использую svn, на ветвление кода уходит меньше минуты.Раньше я использовал Clearcase, на ветвление кода уходило меньше минуты.Я также использовал другие, меньшие SCM, и они либо не поддерживали ветви, либо были слишком болезненными в использовании.Starteam звучит как последнее.

Итак, если вы не можете перейти на более полезный (на самом деле, я слышал только плохое о Starteam), то вам, возможно, придется попробовать другой подход:ручное разветвление.Это включает в себя проверку вашего кода, копирование его в другой каталог, а затем добавление его в качестве нового каталога.Когда вам нужно объединить, вы должны проверить оба каталога и использовать WinMerge для выполнения слияния, вернув результаты в исходный каталог.Неудобно и потенциально сложно, если вы продолжаете использовать ветку, но это работает.

хитрость с разветвлением заключается не в том, чтобы относиться к нему как к совершенно новому продукту.Это ответвление - относительно недолговечное устройство, используемое для отдельного и безопасного внесения изменений в основную магистраль продукта.Любой, кто считает слияние сложным, либо так сильно рефакторингует файлы кода (т. Е. переименовывает, копирует, создает новые, удаляет старые), что ветка становится совершенно другой, либо они хранят ветку так долго, что накопленные изменения мало похожи на оригинал.Вы можете сохранять ветку в течение длительного времени, вам просто нужно регулярно возвращать внесенные изменения обратно.Сделайте это, и ветвление / слияние станет очень простым.

Answer 13

Я делал это всего пару раз, так что мне это не совсем нравится.

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

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

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

Answer 14

Разветвленными необходимо правильно управлять, чтобы сделать слияние безболезненным.По моему опыту (волей-неволей) регулярная интеграция в ответвление от основной линии означала, что обратная интеграция в основную линию проходила очень гладко.

Были лишь редкие случаи, когда слияние не удавалось.Постоянная интеграция от основной линии к филиалу вполне могла включать слияния, но это были лишь небольшие правки, с которыми автоматические инструменты могли справиться без вмешательства человека.Это означало, что пользователь не "видел", как это происходит.

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

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

Answer 15

Чувствуете ли вы себя комфортно, разветвляя код?

Это действительно зависит от инструмента, который я использую.С Starteam ветвление действительно нетривиально (TBH, Starteam отстой в ветвлении).С Git ветвление является обычным действием и выполняется очень просто.

Разветвляете ли вы код по причинам, отличным от замораживания версии-кандидата?

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

• Контроль версий для нескольких гибких команд автор Хенрик Книберг
• Отличительная ветвь автор : Мартин Фаулер

Мне действительно нравится шаблон, описанный в первой статье, и он может быть применен с любой (не распространяемой) системой контроля версий, включая Starteam.

Я мог бы рассмотреть второй подход (фактически, сочетание обеих стратегий) с (и только с) распределенными системами контроля версий (DVCS), такими как Git, Mercurial...

Answer 16

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

Разработчики должны следовать модели "код - тест - фиксация", и если им нужно представление для какой-либо цели тестирования или "рискованной" разработки, они создают его и управляют им.Я управляю репозиторием и создаю ветки только тогда, когда они нам нужны.Такими временами являются (но не ограничиваются ими):

• Производственное исправление
• Проекты с длительными или перекрывающимися циклами разработки
• Обширное переписывание или экспериментальная разработка

Инструмент слияния в StarTeam не самый лучший, но я еще не сталкивался с проблемой, вызванной им.Тот, кто выполняет слияние, просто должен быть ОЧЕНЬ уверен, что он знает, что делает.

Создание представления "Ссылка только для чтения" в Star Team и установка для него плавающей конфигурации позволят изменениям в магистрали автоматически отображаться в ветке.Установите элементы в ветвление при изменении.Это хорошо для параллельных усилий по разработке.

Создание справочного представления "Только для чтения" с помеченной конфигурацией - это то, что вы бы использовали для горячих исправлений существующих производственных выпусков (при условии, что вы их пометили).

Answer 17

Ветвление тривиально, как ответило большинство, но слияние, как вы говорите, нет.

Настоящие ключи - это развязка и модульные тесты.Попытайтесь отделить до того , как вы разветвляетесь и следите за основным, чтобы быть уверенным, что развязка и интерфейс сохранены.Таким образом, когда приходит время объединяться, это все равно что заменить деталь lego:удалите старую деталь, и новая деталь идеально встанет на свое место.Модульные тесты предназначены для того, чтобы гарантировать, что ничего не было сломано.

Answer 18

Ветвление и слияние должны быть довольно простыми.

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

Существует несколько различных моделей ветвей:

Вот один из них

  Trunk          
  .      
  .      
  .      
  ..         
  . ....     
  .   ...
  .      ..Release1
  .      
  .      
  ...        
  .  .... 
  .    ...Release2
  .      
  .      
  ..         
  . ...  
  .  .. 
  .    ...Release3
  .      
  .      

Теперь вот что любопытно.Предположим, что Release1 нуждался в некотором исправлении ошибок.Теперь вам нужно разветвить Release1 для разработки 1.1.Это нормально, потому что теперь вы можете разветвлять R1, выполнять свою работу, а затем слиться обратно с R1, чтобы сформировать R1.1.Обратите внимание, как это позволяет избежать различий между выпусками?

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

  Trunk                                           
  .                                                         
  .                                                         
  .                                                         
  .Release1           
  .                       
  .                       
  .                   
  .                   
  .Release2           
  .                   
  .......                 
  .      ......       
  .           ...DevVer1
  .          .    
  .          .            
  .        ...DevVer2
  .      ....         
  .  ....             
  ...                     
  .Release3           
      .

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

Суть в том, что ваш венчурный капитал должен поддерживать гибкое ветвление и слияние.Системы VCS для каждого файла представляют собой серьезную проблему IMO (RCS, Clearcase, CVS).Говорят, что SVN и здесь доставляет хлопоты, не знаю почему.

Mercurial отлично справляется здесь, как и (я думаю) git.