Подтвердить что ты не робот

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

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

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

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

  • Держите багажник в чистоте.
  • Позвольте разработчику уйти от рискованных изменений.

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

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

Мои вопросы:

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

ОТВЕТЫ

Ответ 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

Ответ 2

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

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

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

Некоторые веские причины для ветвей:

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

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

Для многопользовательской команды:

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

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

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

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

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

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

Ответ 7

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

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

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

Ответ 8

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

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

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

Ответ 9

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

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

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

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

Ответ 10

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

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

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

Ответ 11

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

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

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

Ответ 12

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

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

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

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

Ответ 13

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

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

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

Perforces 3-way merge tools были большой помощью, когда они действительно были нужны.

Ответ 14

Вы чувствуете себя комфортным разветвляющимся кодом?

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

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

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

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

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

Ответ 15

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

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

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

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

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

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

Ответ 16

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

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

Ответ 17

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

Ответ 18

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

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

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

Здесь один

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

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

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

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

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

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

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