How should you create a patch for an older tag in source control?

Question

Let's say I released a version of my software about a year ago and tagged it at 2.3 in Git.

So I keep adding features and fixing bugs and before you know it, the software is now at version 3.0. But now I have a bug on version 2.3 of the software and the person that needs it fixed is not ready to upgrade to version 3.0.

As far as Git is concerned what would be that best way to manage applying a patch to 2.3 and creating version 2.3.1 of the software without changing the history of the Git repo.

For instance, I can't checkout version 2.3, apply the patch and then tag it at 2.3.1 and push it up since that would create a new head.

How do developers typically manage supporting older versions of their software?

Edit

Okay, so I followed @AnoE advise and now my workflow is as follows for patching previous versions. Advice is welcome.

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

The reason I had to create a branch is because the tag wouldn't show up on Kiln, our repo hosting solution. I don't know if other providers like Bitbucket or Github will show a tag without a branch associated or if this is just a side effect of how Git stores things. The tag showed up locally when I ran git tag -l but it wasn't visible through the web UI. After I pushed up the branch and tag I just deleted the branch and it showed up properly from the Web UI.

git push --delete v2_3_1

If anyone has an explanation as to why something like this would happen, it would be appreciated.

Tia

By default, the git push command doesn’t transfer tags to remote servers. you need to run: git push origin <tagname>. in the same way git tag -d <tagname> only do local delete and --delete for remote delete. if you only delete it locally any git clone will make the old tag to pop up again. – Gabor

Answer 1

Checking out version 2.3, applying the patch, tagging it 2.3.1 is exactly what you are going to do.

Creating a new head (rather, a new branch) is not a problem whatsoever, it's what git was made for. Note that "HEAD" has no structural meaning in git, it only stands out because it is the one commit that is active in your current working directory. Git only cares about commits, structurally, and you can have as many "top-level" commits as you like.

So:

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

Keep in mind that both branches and tags are nothing special at all in git. They are simply sticky notes pointing to commits. Making a (maybe temporary) branch in this manner is just a bit more convenient since you can easily switch to/from it if the backport you are doing involves a bit more than one quick commit.

Noland

To add to AnoE's great answer. If you need to push your tags to remote, use: git push origin <tag_name> – Dorothi

One thing I would like to add is: If you want to add a PR for visibility and advice, you can create a branch: release_v2.3.1, and then base your branch dev_2.3.1 on it. make and commit changes. PR and merge into release_v2.3.1 and create the tag v2.3.1 on the latest commit. You may then delete both branches. – Ames

Answer 2

There are two ways of handling releases in Git : tags and branches.

One argument for tags is that they are immutable (you can only delete/recreate them, whereas branches can keep growing), however, I tend to use branches for releases rather than tags for the reasons below :

• If you ever have to patch a release based on a tag, then you will end up with some releases that are tags, some releases that are branches. This can be confusing, especially if you have to patch a second time. This time, you will checkout the first patch branch, so if you ever have to make a patching procedure for people that are not expert with Git, it can be tricky.
• Usually, tools for git (Gitlab, BitBucket, etc) have a page listing branches with a comparison of commits ahead/behind, using a branch as reference. While it's possible to do the same with tags, it just doesn't come up as easy as with branches as you will have to select each tag manually. This is especially useful when you want to make sure that a patch done on an old release is present on a recent release
• Patching doesn't (need to) create new branches. Usually, a patch doesn't cause a problem of backward compatibility, so you might aswell just add a commit to your branch release_2.3 (and just update the pom from 2.3.0 to 2.3.1) and not create a new branch just for the patch, making the parent branch useless anyway (unless some client doesn't want the patch !)

One may argue that tags allow to avoid creating branches and "pollute" the repository with release branches that are not used anymore, but that's a minor downside, considering the "pollution" will come instead from the patches, which we all know, can be as numerous as releases :)

EDIT : You can avoid using branches at all and use 100% tags, but then, if you have to patch an old release, you will have to rebase and rewrite history, which is something I would not recommend

Canalize

Answer 3

Yeah, your updated workflow is a working solution for the Gitlab! There is proof of my fix-old-tag work in case of cherry-pick (or new commits/fixes):

git fetch origin --tags --force
git checkout -b TASK-1063/locale-pkg 1.0.0
git cherry-pick bb8a527 --no-commit
git push --set-upstream origin TASK-1063/locale-pkg
git tag -a 1.1.0 -m "Add locales"
git push origin 1.1.0
git push -d origin TASK-1063/locale-pkg

After that, here is the new 1.1.0 tag is on, HEAD is still upstream with the latest 2.0.1 tag on develop branch, so no destructive changes!

Spandex