10,000 Foot Developer

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.  One of those things can be believing your tool’s view.

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 to remove the tag first.

I learned this when I had tagged a release, but then two changes came in before we actually did the production deployment and it was requested that I move the tag before we deployed.  The moved tag was to be the build devops would pull.

So here’s how it went . . . (general scenario):

• Code spot from our develop branch to merge into release branch at checkin #171.
• Tag the code v4.5.0

To do this was relatively easy, using either SourceTree or command line:

$ git tag v4.5.0
$ git push

Then list them

$ git tag
v4.3.0
v4.4.0
v4.4.1
v4.5.0

Now we had a build.  But wait — the two changes came in:

• checkin #170 to be reverted
• checkin #172 hotfix due to something QA found

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).

The request comes in — move the tag past these changes!

So I merge these particular fixes into our release branch.  And the request to move the tag comes in; sounds simple enough.

$ git tag -d v4.5.0
$ git tag v4.5.0
$ git push

Bow 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:

checkin #172
checkin revert #170
checkin #171 v4.5.6 

Right. The tag didn’t move!  Notably, the gui was *probably* reporting an interesting error about the tag already existing but I did a command line push, and the branches looked tagged properly.  However I forgot to do one thing — push the delete first, then retag, then push again.

$ git tag -d v4.5.0
$ git push
$ git tag v4.5.0
$ git push

Now Bitbucket shows this, correctly:

checkin #172 v4.5.0
checkin revert #170
checkin #171 

Lessons?

1. Don’t believe your GUI tool — always check the target repo to make sure.
2. There may be errors being reported by your gui — take them seriously and fix them.
3. Get another developer eyes on it just to make sure.
4. If you do not do this regularly — as many of us do not — be very very meticulous and be very atomic.

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.

Further Reading

https://git-scm.com/book/en/v2/Git-Basics-Tagging

https://confluence.atlassian.com/bitbucket/how-do-i-remove-or-delete-a-tag-from-a-git-repo-282175551.html

http://stackoverflow.com/questions/1125968/how-to-force-git-pull-to-overwrite-local-files

http://stackoverflow.com/questions/19298600/tag-already-exists-in-the-remote-error-after-recreating-the-git-tag

http://stackoverflow.com/questions/8044583/how-can-i-move-a-tag-on-a-git-branch-to-a-different-commit