Управление версиями и исправление ошибок в SCM

Question

Мне очень жаль ужасное название вопроса, но я попытаюсь объяснить себя более многословно:

Я использую Git (но я думаю, что конкретное программное обеспечение не имеет большого значения в этом случае) для моего программного проекта. Как и многие проекты, я планирую выпустить разные релизы. Когда выйдет релиз, я бы, вероятно, назначил тэг коммита - например, & Quot; 1.0 & Quot ;. Время идет, и код взломан, и в конце концов есть релиз с другим тегом - на этот раз & Quot; 2.0 & Quot;.

Однажды я заметил серьезную ошибку, которая присутствует в обеих версиях 1.0 и 2.0, и ее необходимо исправить. Чтобы сделать вещи сложными (и, вероятно, более реалистичными), я не могу просто исправить это в текущем master / trunk и предположить, что все будут использовать это, потому что есть некоторые обратные несовместимости в 2.0 с 1.0, и люди ленивы и дона не хочу обновляться.

Итак, что было бы хорошей схемой для поддержки такого поведения: возможность вносить изменения в более старые версии. Git, похоже, приравнивает теги к релизам на каком-то уровне из-за вывода команды git describe (& Quot; [latest tag]-[commits since the tag]-[current commit hash] & Quot;). Я, вероятно, не могу избежать использования тегов в целом.

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

Answer 1

Вы определенно хотите использовать ветку для этого. Git поддерживает ветки для этого типа разработки очень хорошо.

Например, ваша линейная история версий может выглядеть следующим образом:

---A---B---C[1.0]---D---E---F[2.0]---G---H

Если вы обнаружили ошибку в версии 1.0 и хотите ее исправить, вы не можете просто вставить новый коммит между коммитами C и D. Таким образом, вы можете создать ветку, подобную этой:

---A---B---C[1.0]---D---E---F[2.0]---G---H[2.1]
            \
             C1---C2[1.1]

Коммиты C1 и C2 решают проблему в этой ветке, где вы можете пометить выпуск 1.1. Теперь предположим, что вы внесли изменение (G) в версию 2.1, которое вы хотели бы перенести обратно в версию 1.1, чтобы сделать там то же самое изменение. Вы можете использовать git cherry-pick для выполнения следующих действий:

---A---B---C[1.0]---D---E---F[2.0]---G---H[2.1]
            \
             C1---C2[1.1]---G1[1.2]

Коммит G1 связан с коммитом G, за исключением того, что он может применяться поверх версии 1.1 вместо версии 2.0.

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

Answer 2

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

Answer 3

Похоже, вы уже получили большую часть ответа, когда упоминаете ветви и теги. Есть тег, чтобы отметить определенный чет (например, релиз), а ветки предназначены для параллельной разработки. Обслуживание определенной версии обычно выполняется в ветви, и вы можете использовать наборы изменений с большинством текущих VCS, чтобы импортировать данное исправление ошибки из головы / ствола в ветку и наоборот.

Вы можете работать с head / trunk / master (независимо от того, что вы & используете; текущее & имя; ветка разработки называется) и объединять исправления в различных ветках обслуживания. Как только вы выполнили основной или вспомогательный выпуск, вы создадите ветку для обслуживания.

Есть много способов добиться того, чего вы хотите.