dot
dot

Reputation: 15660

Changing / adding files to a git tag?

I'm just familiarizing myself with git and now, git tags. Based on what I've understood to date, tags are just a snapshot of a point in time in history that we want to track. For example, for version numbers.

I have a client who wants me to add / backport a bug fix to version 1.0 when we are now on version 2.0. The idea being that when we image a new v1.0 box, the bug fix is included.

I'm not sure how I would do this.

I have the following tags in the repo:

v2.0
v1.0
v0.1

I've tried to check out the tagged version by running the command

git checkout v1.0

Then I made my bug fix changes. And then I tried:

git add .
git commit
git push

When I do the push, I get an error message stating that the updates were rejected because a pushed branch tip is behind its remote counterpart.
I'm currently googling this error but I would like to know if fundamentally, I'm doing something that I shouldn't.

Upvotes: 3

Views: 12586

Answers (2)

Andrew C
Andrew C

Reputation: 14823

You are confusing tags with commits. Usually tags are analogous to pointers to commits.

For your scenario a typical model would be as follow

# Create a release branch for v1 
git checkout -b v1_release v1.0
# make your bug fixes, `git commit`, etc.
emacs foo
git add foo
git commit -m "critical bug fix"
# tag your new release 
git tag v1.1
# push the branch and the tags to the server 
git push ...

To see what versions have the fix you would use git branch --contains FIX_SHA or git tag --contains FIX_SHA

You could also create a v2_release branch and git merge the fix there.

I would never recommend reusing the same version number for two different code images that were flashed onto hardware. That sounds like a customer relations and support nightmare.

Upvotes: 2

Ionică Bizău
Ionică Bizău

Reputation: 113335

Overriding a tag/version is a bad practice in general. Since you only want to fix a bug from an older version, they way git works is to create a new tag with that bug fixed.

That's why we have CHANGELOG thing -- it helps humans to view the differences between versions/releases.

In the case of fixing a bug in an older version (v0.1.0) while a new version (v0.2.0) has log of changes and cannot be synced with the old one, you probably want to create a new tag like v0.1.1:

# creating v0.1.0
git init
echo "console.log('Hello Wrold')" > main.js
git add .
git commit -m 'Initial commit'
git tag v0.1.0
git remote add origin ...
git push --all
git push --tags
# creating v0.2.0
echo "console.log('Hello Mars')" > main.js
git commit -m 'Hello Mars instead of Hello world' .
git tag v0.2.0
git push --all
git push --tags
# fixing typo from v0.1.0 (edit/add files) and creating v0.1.1
git checkout v0.1.0
echo "console.log('Hello World')" > main.js
git commit -m 'Fixed typo.' .
git tag v0.1.1
git push --tags
# go back to main branch
git checkout master

Fixed typo. commit will not appear in master branch since it was added only in v0.1.1 tag.


So, what if I want to override v0.1.0? If that's a bad practice, doesn't make it impossible. Instead of creating a new version (git tag v0.1.1) we can delete the old v0.1.0 and create it again, forcing pushing on remote:

... # fixed typo
git tag -d v0.1.0
git tag v0.1.0
git push --tags -f
# go back to main branch
git checkout master

On GitHub, it releases will be listed like this:

Let's see the differences:

$ git diff v0.1.0 v0.2.0 
diff --git a/main.js b/main.js
index 07e8cb2..7b366c5 100644
--- a/main.js
+++ b/main.js
@@ -1 +1 @@
-console.log('Hello Wrold')
+console.log('Hello Mars')
$ git diff v0.1.1 v0.2.0
diff --git a/main.js b/main.js
index ba72797..7b366c5 100644
--- a/main.js
+++ b/main.js
@@ -1 +1 @@
-console.log('Hello World')
+console.log('Hello Mars')
$ git diff v0.1.0 v0.1.1
diff --git a/main.js b/main.js
index 07e8cb2..ba72797 100644
--- a/main.js
+++ b/main.js
@@ -1 +1 @@
-console.log('Hello Wrold')
+console.log('Hello World')

Upvotes: 7

Related Questions