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

Question

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

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

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

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

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

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

Мои вопросы:

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

Answer 1

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

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

• Контроль версий для нескольких Agile команд Хенрик Книберг
• FeatureBranch от Martin Fowler

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

Answer 6

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

Мы также выпускаем ветки.

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

Answer 7

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

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

Есть несколько разных моделей веток:

Вот один

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

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

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

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

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

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

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

Answer 8

Я делал это только пару раз, поэтому мне это не совсем удобно.

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

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

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