Предпочтительная методология контроля версий - PullRequest
16 голосов
/ 20 января 2009

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

Одна вещь, которую я заметил, это довольно четкое разделение методов разработчиков на две (возможно, больше?) Группы: одна группа предпочитает держать свой ствол в всегда стабильном состоянии и выполняет все обслуживание и дальнейшую разработку в ветви, в то время как другие предпочитают делать все свое развитие в стволе и держать его в не очень стабильном состоянии.

Мне любопытно, что предпочитает сообщество в StackOverflow или есть ли у вас свои собственные методы.

Примечание. Если это поможет адаптировать ответы, я должен отметить, что я являюсь одним разработчиком (не более двух или трех других в одном проекте), который работает в основном в ASP.NET и SQL Server 2005 * 1007. *

Ответы [ 11 ]

0 голосов
/ 14 июля 2009

Одним из ключевых отличий является то, насколько большие файлы имеют тенденцию быть в среднем. Большие файлы (более 1000 строк), как правило, имеют много независимых изменений, которые легко объединяются. Поэтому тот факт, что кто-то еще активно изменяет файл, над которым вы собираетесь начать работу, вероятно, неинтересен, поэтому вполне нормально, если система затруднит его обнаружение.

Таким образом, вы склоняетесь к стратегии ВК, которая имеет много ветвей и простых слияний. Новый функционал написан в новых ветках.

Если вы работаете с небольшими, сильно связанными файлами, типичными для дизайна ОО, на языке, подобном Java, такие случайные конфликты встречаются гораздо реже. Даже в качестве искусственного примера довольно сложно придумать два набора изменений, которые можно внести в класс (и соответствующие тестовые случаи JUnit), которые можно сделать разумно изолированно, а затем автоматически объединить с помощью инструмента слияния текста. .

Если вы много реорганизуете (переименовываете и разбиваете файлы), это еще больше подчеркивает инструмент слияния.

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...