Лучший способ управлять Source Control для немного разных версий одной и той же кодовой базы

Question

Я видел, что этот вопрос задавался несколькими разными способами, и каждый раз ответы - это обходные пути или способы, при которых не нужно поддерживать 2 или более разных версий.Тем не менее, я не думаю, что есть какие-либо обходные пути, учитывая мою среду (Visual Foxpro).В настоящее время я поддерживаю 2 разных репозитория:

• Live - код в работе
• Proof - иногда идентичен Live, но обычно этополигон для тестирования любого из ряда новых функций, а также область подготовки для изменений в Live

Я просто не вижу способа справиться с ситуацией с ветками, потому что Proof тратит больше всего (если нетвсе) пора больше походить на вилку.Например, в настоящее время существует большой раздел кода, который кардинально отличается от Live, с которым мы играем уже почти год.В настоящее время есть также около 10 второстепенных функций, которые отличаются от Live и находятся на разных стадиях утверждения.

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

Прав ли я, что Proof действительно больше похож на форк и поэтому должен храниться в отдельном репозитории?

Кстати, не то, чтобы это так много значило для вопроса, но мой VCS на выбор - Mercurial.

Answer 1

Способ, которым мы делаем это в моем магазине, заключается в том, чтобы использовать default и stable ветви , чтобы сохранить код, который фактически выпускается (в режиме реального времени), отдельно от того, над чем он работает.*

В дополнение к именованным ветвям у нас есть клон для каждой новой существенной функции / дополнения.Нам это немного удобнее, чем иметь несколько голов в ветви default.

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

Answer 2

Я не знаю, насколько это применимо к вашей конкретной ситуации, но можете ли вы сохранить каждое из текущих изменений как отдельную ветку, и чтобы Proof был текущим Live со всеми этими дополнительными ветвями, объединенными? Тогда это будет очень перспективной проверкой интеграции, и вы также будете знать, что каждая ветвь должна быть объединена с Live (при условии, что она не зависит от того, что еще не было объединено).