Как разработчики используют систему управления версиями? Я пытаюсь найти наиболее эффективный способ управления версиями в небольшой среде разработки.

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

В долгосрочной перспективе лучше оставить основную ветку в качестве ветки разработки и создать отдельную ветку поддержки для каждого конкретного релиза; это делает пути ваших ветвей короткими. (Я работал над проектом, где путь фактической рабочей ветки был что-то вроде main/release_1.0/release_1.1/release_1.5/release_2.0/release_2.1... вы не хотите идти по этому переулку :-)

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

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

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

Вот отличная ссылка рейнджеров VSTS от Microsoft по некоторым стратегиям ветвления системы управления версиями. У него есть несколько различных опций в зависимости от размера вашей команды и желаемого уровня контроля.

http://branchingguidance.codeplex.com/

Отметьте/разветвите каждый выпуск и оставьте его нетронутым. У них есть ветка разработки и ветка поддержки. Пусть поддержка/исправления ошибок работают в ветке поддержки, а затем новые функции разрабатываются в ветке разработки. Вы можете создавать промежуточные выпуски исправлений ошибок для производственного программного обеспечения по мере продвижения, не вводя новый код из ветки dev, это ваши второстепенные приращения версии, например. переход от 1.0 к 1.1 или 1.01 и т. д. Затем, когда цикл разработки заканчивается и вы готовы сделать выпуск, вы объединяете ветки разработки и поддержки для создания выпуска с новыми функциями + исправлениями ошибок, это ваши основные выпуски, например. 1.x до 2.x или 1,2x до 1,3x. Очень важно тщательно документировать все исправления ошибок в ветке поддержки. Таким образом, прежде чем объединять ветки поддержки и разработки, вы можете проверить каждую из них по отдельности, чтобы увидеть, какое вероятное влияние будет на ветку разработки, например. это исправление ошибки в ветке поддержки, исправление чего-то, что было полностью переписано в ветке разработки и поэтому должно быть полностью исключено из следующего основного выпуска.

Я повторяю свой ответ на предыдущий вопрос. YMMV, но это обзор нашего текущего процесса разработки (у нас здесь около 10 разработчиков, и мы используем SVN для контроля версий):

Вот наш типичный цикл разработки; мы «псевдо agile»; и запустить 2-недельный цикл выпуска.

Все проекты начинаются на ответвлении от ствола. Без исключений.

Как только проект завершен и проверка кода завершена, разработчику дается зеленый свет на объединение этой ветки в основную ветку. Туда; ни один код, который не был тщательно проверен, не попадает в ствол. Мы используем CruiseControl для непрерывной интеграции, поэтому после фиксации в магистрали, если какие-либо тесты не пройдут, разработчик несет ответственность за их исправление. Эти исправления идут на багажнике.

За неделю до следующего релиза; мы создаем «тег» выпуска (по сути, другую ветку) и отправляем его в QA. Если вы не влили свой код обратно в ствол на этом этапе, он не выйдет со следующим выпуском. (Важное примечание: этот «тег» релиза никогда не объединяется обратно с основной веткой. Никогда.) По мере того, как QA находит ошибки; они возвращаются разработчику. Когда разработчик их исправляет; их изменения должны быть зафиксированы как в теге выпуска, так и в стволе.

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

Намыльте, промойте, повторите...

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

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

Эта книга не посвящена конкретно TFS, но может быть полезно получить некоторые сведения об использовании контроля версий на практике и о том, как применять различные «методы», такие как ветвление.

Прагматичный контроль версий http://oreilly.com/catalog/9780977616657

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

http://svnbook.red-bean.com/nightly/en/svn.branchmerge.commonpatterns.html