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

Question

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

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

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

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

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

Answer 1

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

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

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

Answer 2

Вы определенно хотите использовать для этого ветку. 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 3

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