Reputation: 15660
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
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
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