My repository has a branch production and is filled with countless tags of the format production-20130101-1234 that point to what has been actually shipped on the given datetime.
I think this solution is somewhat messy and unwieldy and I wonder if reflogs would skip in here better. The objective is “make sure you can always find out what version has been deployed and when exactly”.
Tags do the job, but reflogs sound even nicer because:
- They are made automatically,
- They allow a good amount of awesome, like in the form of
git checkout origin/production@{3 months ago}.
That said, I don’t know that much about reflogs and I’m not sure about possible downsides of such approach.
- I assume
origin/productionhas its own reflog totally independent of my local remote-trackingproduction– is that correct? - Doing 3 consecutive no-ff merges from an integration branch to my local
productionbranch would make 3 entries in my local reflog, but pushing it to the central repo (as a part of the deployment procedure) would make 1 new entry in the “oracle”origin/productionreflog, correct?
I’d like to maintain the “1 deployment = 1 record” invariant. - How to make sure a reflog of
origin/productionisn’t pruned and continues to provide complete historical information for everyone? - Any downsides or possible problems I didn’t think of?
1
The main problem is that reflog is local thing and never propagated anywhere. So the data would be somewhat difficult to get at.
One alternative of tags that comes to my mind is a branch with subproject. Git tree can contain a link to a commit. So you can create a repository above the actual project and when you deploy, commit with the correct submodule revision. I am not sure whether it would be possible to have is somewhere on the side with the subproject included via symlink. I am sure though that it would be possible to write a utility for creating such revisions in the repository without actually having a work tree at all (git creates commits from state of index only and you can manipulate the index directly via commands and you can tell git to use different index file). It would take some work though.