Как создать патч для старого тега в исходном элементе управления?

Question

Предположим, я выпустил версию своего программного обеспечения около года назад и пометил ее на 2.3 в Git.

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

Насколько Git обеспокоен тем, что было бы лучшим способом управления применением патча до версии 2.3 и созданием версии 2.3.1 программного обеспечения без изменения истории Git repo.

Например, я не могу проверить версию 2.3, применить патч, а затем пометить его на 2.3.1 и нажать на него, так как это создаст новую голову.

Как разработчики обычно управляют поддержкой более старых версий своего программного обеспечения?

Редактировать

Хорошо, так что я последовал @AnoE советовать и теперь мой рабочий процесс выглядит следующим образом для исправления предыдущих версий. Совет приветствуется.

git checkout v2.3.0 
// Make code changes 
git add -A 
git commit -m "Fixed a bug in old app" 
// Do something to verify the changes work on a different environment 
git checkout -b v2_3_1 
git tag -a v2.3.1 -m "Fixed small bug." 
git push origin v2_3_1 
git push --tags 

Причина мне пришлось создать ветку, потому что метка не будет отображаться на печи, наш хостинг репо решения. Я не знаю, будут ли другие поставщики, такие как Bitbucket или Github, показывать тег без связанной ветки или если это просто побочный эффект того, как Git хранит вещи. Тег появился локально, когда я запустил git tag -l, но он не был виден через веб-интерфейс. После того как я нажал на ветку и тег, я просто удалил ветку, и она появилась правильно из веб-интерфейса.

git push --delete v2_3_1 

Если у кого-нибудь есть объяснение, почему произошло бы подобное, это было бы оценено.

Answer 1

Проверка версии 2.3, применение патча, пометка 2.3.1 - это именно то, что вы собираетесь делать.

Создание новой головы (скорее, новой ветки) не является проблемой вообще, это то, что было сделано для git. Обратите внимание: «HEAD» не имеет структурного значения в git, он выделяется только потому, что он является активным в вашем текущем рабочем каталоге. Git только заботится о коммитах, структурно, и вы можете иметь как можно больше «верхних уровней», как вам нравится.

Итак:

git checkout 2.3 # gives you a "detached HEAD" 
git checkout -b dev_2.3 # a new branch, more for convenience 
...modify files... 
git add ... ; git commit ... 
git tag 2.3.1 
git branch -D dev_2.3  # get rid of it if you have a feeling that you won't be comming back soon 

Имейте в виду, что обе ветви и теги, ничего особенного вообще в мерзавца. Это просто липкие заметки, указывающие на фиксации. Создание (возможно, временного) ветви таким образом является чуть более удобным, так как вы можете легко переключиться на него/из него, если ваш задний ход включает в себя несколько более быстрых фиксаций.

Answer 2

Существует два способа обработки выпусков в Git: теги и ветки.

Одним из аргументов для тегов является то, что они неизменны (вы можете удалить/обновить их, в то время как филиалы могут продолжать расти), однако, я предпочитаю использовать ветви для релизов, а не теги по следующим причинам:

• Если вам когда-либо понадобится исправить выпуск на основе тега, вы получите несколько выпусков, которые являются тегами, некоторые выпуски, которые являются ветвями. Это может сбивать с толку, особенно если вам придется исправлять второй раз. На этот раз вы проверите первую ветку патча, поэтому, если вам когда-либо понадобится сделать процедуру исправления для людей, которые не являются экспертами с Git, это может быть сложно.
• Как правило, инструменты для git (Gitlab, BitBucket и т. Д.) Имеют ветви списка страниц со сравнением комманд впереди/позади, используя ветку в качестве ссылки. Хотя можно сделать то же самое с тегами, это просто не так просто, как с ветвями, так как вам придется выбирать каждый тег вручную. Это особенно полезно, если вы хотите убедиться, что патч, сделанный в старой версии, присутствует в недавнем выпуске
• Патч не требует создания новых ветвей. Как правило, патч не вызывает проблемы обратной совместимости, поэтому вы можете просто добавить фиксацию в свою ветку release_2.3 (и просто обновить pom от 2.3.0 до 2.3.1), а не создать новую ветку только для патча, что делает родительскую ветку бесполезной в любом случае (если какой-либо клиент не хочет патч!)

Можно утверждать, что теги позволяют избежать создания ветвей и «загрязнять» репозиторий с ветвями выпуска, которые не являются но это второстепенный недостаток, учитывая, что «загрязнение» придет вместо этого из патчей, которые, как мы все знаем, могут быть такими же многочисленными, как релизы :)

EDIT: вы можете вообще не использовать ветки и использовать 100 %, но тогда, если вам нужно исправить старую версию, y ou придется переустанавливать и переписывать историю, что я бы не рекомендовал