Git Branching and Environment Deployment Tracking

We're moving our source control from VSS to Git (and VERY happy about that). I'm trying to determine the best strategy in Git to track which versions of our code are deployed on which boxes in our environment. So far we've only dedicated our GitHub master branch to exclusively represent what is in production ONLY. No commits will happen on this branch unless done by the configuration man开发者_运维百科agement team to record what was successfully applied to production.

Do people also create separate branches for all their environments or use tags? I've seen the branching model proposed but it seems like that would require a lot of unnecessary, and potential painful, merging.

I think tags would be a great solution but how do people implement this? Let's say I have 3 QA environments named QA1, QA2, QA3. If I just deployed code from branch origin/hotfix42 to box QA2, would I maybe use a tagging nomenclature like "QA2-060911_511pm" that tells me which version of code was deployed onto which box at what time? But if I did do this, my database of tags over time is going to grow into the hundreds and even thousands. So if I wanted to find the current version deployed to QA2, how would query through all the tags to find the most current? Or.... would I always add an extra tag just named QA2_Current? But then continually have to keep removing that tag and adding to other versions as deployments happen?

Are there any other mechanisms to add metadata to commits? For instance, could I add an env variable to my commits and then search commits where env=QA2?

Thanks

---

The rule of thumb is you use tags for things that will never change (like version 1.0.0 always points to the same commit), and use branches for things that do change (like the "latest" version).

So I would recommend the current version deployed to QA2 to be designated by git branch QA2, and moved as appropriate by adding a -f to the command. No need to do complex merges if you're just using it as a "movable tag."

The times you might want to do merges instead of just moving the branch is if you need to retain a historical sequence of what was deployed in the past. For a short time, you can use QA2@{1}, QA2@{2}, etc., but those eventually get erased by git gc.

Also, keep in mind that merging in git is orders of magnitude less painful that what you're probably accustomed to. You might want to give those models a try before dismissing them as too difficult.

---

To answer your question about finding the newest tag, if you're on unix you can run this to list the tags sorted by the commit dates:

git tag | xargs -I@ git log --format=format:"%ci %h @%n" -1 @ | sort

Note that you can also start the pipeline with any other list of refs / sha hashes. But if you want to list local branches, due to the leading star you'll have to do something like:

git branch | sed 's/^\*//' | xargs -I@ git log --format=format:"%ci %h @%n" -1 @ | sort