问题
I'm working on a web project with frequent merges and releases into production. I'd like the repository to contain a full record of everything that was ever pushed onto the production server, mainly so that I can analyse an error log entry from three weeks ago knowing exactly what code was in production at that time.
I cannot use a release branch for this because in Git, there is no concept of a history of commits made on a specific branch. We do use a release branch currently, but it does not enable me to answer the question of "what code was in production three weeks ago".
So, how should I do this in Git?
回答1:
Tags are intended for this kind of use on git. You can read about tags here.
As per your question, you can have a list of all tags, hence knowing what has been released. The example for this on git scm-book is:
$ git tag -l 'v1.4.2.*'
v1.4.2.1
v1.4.2.2
v1.4.2.3
v1.4.2.4
Checking out a specific tag would put you in the exact same condition as when the code was released.
You can even GPG sign the tags, which can be helpful in a shared repository, should you bother about anybody mixing things up (either on purpose or by accident).
Please note that:
By default, the git push command doesn’t transfer tags to remote servers. You will have to explicitly push tags to a shared server after you have created them. This process is just like sharing remote branches — you can run git push origin [tagname].
as this could result in a terrible headache if you assumed it did.
As always in git, all you really need is the sha of the commit, so that writing that down could be sufficient, depending on your needs.
回答2:
If each code push to production is a merge into the release branch, you will have commits named Merge branch 'master' into release, with a timestamp for the moment that merge took place. On git's log, by default you just see the current branch's commits, so you can see what was in production by using the merge's timestamps to determine what is the latest commit in the release branch that was pushed at the time.
回答3:
When you build release for production, you can either create a tag that represents this particular build or simply save the current SHA1 hash of that particular commit.
With some extra build logic, you can brand-mark your release with this hash number, that uniquely identifies your release. Some examples how to do that in ANT-Builds can be found here.
来源：https://stackoverflow.com/questions/17654416/how-to-record-a-history-of-releases-for-a-web-project-in-git