Похоже, вы пытаетесь реализовать стратегию ветвления функций. Однако, исходя из вашей диаграммы, я думаю, что вы пропустили несколько шагов и / или объединяете неправильные ветви. По сути, у вас, вероятно, должно быть более 4 линий разработки плюс 1, представляющая все ветви функций. К сожалению, мне не удалось найти хорошую диаграмму, за исключением одного разговора о Git и работоспособной стратегии ветвления здесь . Диаграмма, тем не менее, лучше объясняет, что вы ищете, даже если вы используете другой DVCS, такой как Mercurial (моя любимая). Используя Руководство по ветвлению в Mercurial и Hg Book Стива Лоша, вы сможете реализовать хорошую стратегию ветвления функций, которая работает для вас. У Стива есть плюсы / минусы для каждого подхода.
И, нет, вам не нужно клонировать, чтобы правильно разветвляться. В Mercurial есть именованные ветви, которые позволяют легко переключаться между ветками, если вы обычно работаете над несколькими незавершенными элементами и / или выполняете проверки / тестирование кода для других разработчиков. При любой веб-разработке с IIS легче работать с именованными ветвями, так как вещи не перемещаются, и разные версии могут продолжать работать с той же конфигурацией в IIS.
Я должен сказать, однако, что ветвление объекта или любое другое имя, которое вы ему даете, почти всегда является плохой идеей, поскольку ветки, которые работают слишком долго (скажем, год, который я видел с катастрофическими результатами), практически невозможно объединить вернуться, если вы часто (ежедневно) управляете синхронизацией между ветвью функции и ее родителем. Этот тип накладных расходов на обслуживание не стоит хлопот, и вам лучше придерживаться основанной на транках разработки с ветвями релиза для исправления ошибок и исправления кода в абстрактном коде, который используется в производстве и не завершен.