![](\"http:\/\/10kdev.net\/wp-content\/uploads\/2016\/09\/46b578f3136d1848b9d3a70d72b5d038.png\")
<\/p>\n<\/p>\n
If you are a daily developer like me, but not a release manager, getting called on to do release activities can be a frustrating thing. \u00a0One of those things can be believing your tool’s view.<\/p>\n
Be careful – if you’ve updated your git tags – local SourceTree will show git tags at a spot that is not the same place as bitbucket if you do not do a discrete push\u00a0to remove the tag first.<\/strong><\/p><\/blockquote>\n
I learned this when I had tagged a release, but then two changes\u00a0came in before we actually did the production deployment and it was requested that I move the tag before we deployed. \u00a0The moved tag was to be the build devops would pull.<\/p>\n
So here’s how it went . . . (general scenario):<\/p>\n
\n
- Code spot from our develop branch to merge into release branch at checkin #171.<\/li>\n
- Tag the code v4.5.0<\/li>\n<\/ul>\n
To do this was relatively easy, using either SourceTree or command line:<\/p>\n
$ git tag v4.5.0\r\n$ git push\r\n<\/code><\/pre>\nThen list them<\/p>\n
$ git tag\r\nv4.3.0\r\nv4.4.0\r\nv4.4.1\r\nv4.5.0<\/code><\/pre>\nNow we had a build. \u00a0But wait — the two changes came in:<\/p>\n
\n
- checkin #170 to be reverted<\/li>\n
- checkin #172 hotfix due to something QA found<\/li>\n<\/ul>\n
Now don’t ask me why in this process we jusst didn’t wait, but, some places follow this process. (The old days we build an artifact, these days on most systems we tag the repo and build, build, build).<\/p>\n
The request comes in — move the tag past these changes!<\/p>\n
So I merge these particular fixes into our release branch. \u00a0And the request to move the tag comes in; sounds simple enough.<\/p>\n
$ git tag -d v4.5.0\r\n$ git tag v4.5.0\r\n$ git push\r\n<\/code><\/pre>\nBow SourceTree is reporting on BOTH REMOTE AND LOCAL release instances that the tag has been moved but you know what? When I go and look out on Bitbucket I see:<\/p>\n
checkin #172\r\ncheckin revert #170\r\ncheckin #171 v4.5.6 <\/code><\/pre>\nRight. The tag didn’t move! \u00a0Notably, the gui was *probably* reporting an interesting error about the tag already existing but I did a command line push, and\u00a0the branches looked tagged properly. \u00a0However\u00a0I forgot to do one thing — push the delete first, then retag, then push again.<\/p>\n
$ git tag -d v4.5.0\r\n$ git push\r\n$ git tag v4.5.0\r\n$ git push\r\n<\/code><\/pre>\nNow Bitbucket shows this, correctly:<\/p>\n
checkin #172 v4.5.0\r\ncheckin revert #170\r\ncheckin #171 \r\n<\/code><\/pre>\nLessons?<\/p>\n
\n
- Don’t believe your GUI tool — always check the target repo to make sure.<\/li>\n
- There may be errors being reported by your gui — take them seriously and fix them.<\/li>\n
- Get another developer eyes on it just to make sure.<\/li>\n
- If you do not do this regularly — as many of us do not — be very very meticulous and be very atomic.<\/li>\n<\/ol>\n
Git tags are an interesting beast. They are very flexible. And are subject to not obeying compound changes (delete, recreate) in a single action so be careful.<\/p>\n
Further Reading<\/em><\/p>\n
https:\/\/git-scm.com\/book\/en\/v2\/Git-Basics-Tagging<\/a><\/p>\n
https:\/\/confluence.atlassian.com\/bitbucket\/how-do-i-remove-or-delete-a-tag-from-a-git-repo-282175551.html<\/a><\/p>\n
http:\/\/stackoverflow.com\/questions\/1125968\/how-to-force-git-pull-to-overwrite-local-files<\/a><\/p>\n