Различные подходы к ветвлению контроля версий

Question

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

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

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

Провел некоторое последующее исследование и нашел это: http://www.lostechies.com/blogs/derickbailey/archive/2009/07/15/branch-per-feature-source-control-introduction.aspx

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

Answer 1

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

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

Answer 2

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

Изменения делаются на отдельных ветвях. Это дает лучшую прослеживаемость, и можно использовать управление исходным кодом в ветви и проверять промежуточные версии. В идеальном мире вопросы слияния охватываются [автоматическими] тестами. Чем раньше вы интегрируете изменения в ствол, тем лучше.

Не помещайте непроверенный код в транк, так как это в конечном итоге замедлит кого-либо.

Answer 3

Это очень похоже на этот предыдущий вопрос SO:

Subversion - разве кто-нибудь должен разрабатывать со ствола?

Не совсем идентично, но многие понятия в ответах одинаковы.

Мое личное мнение? Ствол для активного развития; Линии разработки старых версий, которые вы хотите сохранить "нетронутыми", должны содержаться в ветках версий (и тегах для выпусков). Вы все еще можете попытаться сохранить максиму «транк всегда должен компилироваться» даже при активной разработке в транке.