I have a git repository with two branches; one for code that's used for manufacturing/test and one that's the actual production firmware (they're nearly identical). It's now time to cut a release to send to the manufacturer, so I naturally want to put down some appropriate tags on both branches.
But, it seems that git won't let me put the same tag name on both branches. If I try to tag the branches individually it tells me the tag already exists when I go to tag the seconds branch. I tried passing two commits to git tag, but it didn't like that either. I don't necessarily need to always tag the two branches in lockstep, but I don't want to add random characters to the tags just to avoid name collisions.
Is there some way to do what I want, or am I wanting to do the wrong thing?
One branch is the code that manufacturing puts on the device to test that it was assembled properly. The other branch is the code that ships in the product. It's not really two branches per release. This is the first release for this product, and therefore first release for both branches, so I tried to tag both branches with 'release-1.0'.
You're wanting to do the wrong thing. The purpose of a tag is to unambiguously identify a particular revision. If I were you, I'd tag only the production branch and leave the testing branch untagged.
However, it's pretty weird that you've got two independent branches per release. Why is this? The answer might help to describe a better solution.
Since the tags aren't really supposed to point to the same revision, but (potentially) different revisions, the tags should be something like this:
appname-1.0-manufacturingappname-1.0-production
That way, you will know which release each tag belongs to, as well as where the code ended up.
A tag just gives a name to a single commit, so no, there probably isn't a way to do what you want.
I'm curious what the desired result would be. I mean, one purpose of a tag is to be a name that you can checkout later. So if you git checkout on a tag that refers to two branches.. what happens?
Coming to the party late, but another alternative would be to merge the two branches, so at any point a commit contained the state of the testing code and production code, assuming they can co-exist without conflicts (in which case it comes down to how hard that merge would be whether it would be worth attempting this). This would also help to avoid situations where you accidentally tag the wrong branch, as may well occur with trying to keep the testing branch and the production branch in sync when you tag them.
