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

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

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

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

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

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

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

• Управление версиями для нескольких гибких команд Хенрика Книберга
• FeatureBranch Мартина Фаулера

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

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

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

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

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

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

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

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

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

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

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

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

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

Для нескольких особенность команды person:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот одна

  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.

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

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

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

I use svn, it takes less than a minute to branch code. I used to use Clearcase, it took less than a minute to branch code. I've also used other, lesser, SCMs and they either didn't support branches or were too painful to use. Starteam sounds like the latter.

So, if you cannot migrate to a more useful one (actually, I've only heard bad things about Starteam) then you might have to try a different approach: manual branching. This involves checking out your code, copying it to a different directory and then adding it as a new directory. When you need to merge, you'd check out both directories and use WinMerge to perform the merge, checking in the results to the original directory. Awkward and potentially difficult if you continue to use the branch, but it works.

the trick with Branching is not to treat it as a completely new product. It is a branch - a relatively short-lived device used to make changes separately and safely to a main product trunk. Anyone who thinks merging is difficult is either refactoring the code files so much (ie they are renaming, copying, creating new, deleting old) that the branch becomes a completely different thing, or they are keeping the branch so long that the accumulated changes bear little resemblance to the original. You can keep a branch for a long time, you just have to merge your changes back regularly. Do this and branching/merging becomes very easy.

The branching problem is why I use a Distributed Version Control system (Git in my case, but there are also Mercurial and Bazaar) where creating a branch is trivial.

I use short lived branches all the time for development. This lets me mess around in my own repository, make mistakes and bad choices, and then rebase the changes to the main branch so only clean changes are kept in history.

I use tags to mark frozen code, and it is easy in these systems to go back and branch off these for bug fixes without having a load of long lived branches in the code base.

We use svn. It only takes us about 5 minutes to branch code. It's trivial compared to the amount of pain it saves us from messing up trunk.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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