5

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?

Roman Starkov
  • 59,298
  • 38
  • 251
  • 324
  • 1
    Why not tagging the commits as "released $timestamp"? That works nicely for automated deployment. – mbx Jul 15 '13 at 12:42
  • @mbx Sure, I don't know. I'm asking here :) In all other SCM's I've used before, I would have used a branch, but I can't in Git, hence the question. – Roman Starkov Jul 15 '13 at 12:43
  • Wouldn't setting a tag each time you release meet your requirements? – Simon Jul 15 '13 at 12:43

3 Answers3

3

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.

Stefano Falasca
  • 8,837
  • 2
  • 18
  • 24
  • Can Git list all the "released"-tagged revisions easily using `git log`? Better still, can I `git checkout `? I'm only asking because I'm used to this being easy in other SCMs I've used. – Roman Starkov Jul 15 '13 at 12:45
  • Yes, you can act on tags like if they were commit hashes in almost every case. – Esteban Küber Jul 15 '13 at 12:48
  • @voyager Does this approach make the `release` branch completely redundant? I think the only reason we have it is to answer this question, but if I'm tagging releases then there's no point in also having a branch (unless I use the strategy you describe in your answer). – Roman Starkov Jul 15 '13 at 12:50
  • @voyager I was just editing the answer for pointing that out! Thank you, I think that's worth saying – Stefano Falasca Jul 15 '13 at 12:51
  • @romkyns, yes I would go with one or the other. Personally, I'm partial to having a branch, but tags are made precisely for this. If you have rolling releases very often (more than daily), using tags will be a major headache as you have to think about what to name them, while using a release you will use a hash. Having a separate branch might make it easier to cherrypick stuff into prod as well. Use tags if instead you have milestone releases in a regular fashion. – Esteban Küber Jul 15 '13 at 13:14
1

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.

Esteban Küber
  • 36,388
  • 15
  • 79
  • 97
1

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.

Community
  • 1
  • 1
joergd
  • 553
  • 4
  • 13