Как лучше всего управлять параллельными версиями в Git? #39;

У меня есть хорошо зарекомендовавший себя программный инструментарий, но который часто нуждается в небольших изменениях (, в основном для решения проблем совместимости с 3-го поколения. товары для вечеринок ). Теперь я хочу создать «новую» версию (улучшенный API ), которая будет основана на оригинальной -и со временем будет отличаться от существующей ветки, но в течение нескольких лет мне нужно будет сохранить оригинальный «живой» для существующих клиентов, которым он нужен для совместимости. Конечно, я также должен убедиться, что "корректировки" применяются и к "новой" версии, так как такие проблемы будут (в большинстве случаев! )также относятся к «новой» версии.

Итак, -мой идеальный (простой )рабочий процесс был бы:

  1. При работе над «новой» версией -изменения применяются только к этому версия.
  2. При работе над "старой" версией все полученные изменения будет (настолько автоматически, насколько это возможно! )применяется к обеим версиям как только я доволен ими (, когда я совершаю, подчиняюсь или что-то в этом роде ).

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

В данный момент я собираюсь отказаться от VSS (да -продолжайте смеяться надо мной за то, что я держу его так долго! ), и я надеялся, что Git упростит эту задачу, но до сих пор не было найдено никаких «простых» решений, а все предложения, которые я видел, основаны на «перебазировании», что кажется «неправильным». " для меня, поскольку rebase, по-видимому, делает много других вещей, таких как переписывание истории, когда все, что мне нужно, это простое,подлинное «движение вперед» на основе изменений из другой ветки.

  • Я что-то упустил?
  • Есть ли более простой, правильно определенный способ сделать это?
  • Будет ли мне лучше использовать другую систему управления версиями, а не Git?

Все мысли высоко ценятся!

9
задан simont 22 April 2012 в 04:08
поделиться