CVS-styled tags implementation in git
I faced with the strange question, that I cannot answer by myself, despite I’ve been working with git for long time.
Process requires to tag single file in
git when it’ll be considered production ready. When other files become ‘ready’ too they need to be ‘tagged’ as well. File was tagged first might change till that moment, but we still need to be able to retrieve all ‘ready’ files at once.
It would work, if it is possible to tag single file in commit, but it is not true.
Could you give me any clue, workaround, how I could achieve this: retrieving several files in several commits linked together by single criterion?
3 Solutions collect form web for “CVS-styled tags implementation in git”
Tagging files for purposes like that requires that the branch that file is checked into does not change, e.g. if some version on the branch is tagged and then the branch is rebases, then the tag will still point to the “old” version and not follow onto the “new” branch. So for a “files not yet delivered” scenario, tagging will probably not work well.
What I think would work better would be to create a special
production_ready branch and then cherry-pick the changes you think is production ready onto that branch. That way, when the actual “deliver to production” shall occur, you just merge the
As per your request,
Do your development of software using git. Do the normal
git add . and
git commit -m "commit message" process of adding new changes to the index and commiting them to your repository as needed.
At the end of the day, you will want to make the uppers happy and check-in all of your current work to the other CM system. The issue is that this system requires you to tag/label every file instead of a “set” of files. You can handle this problem by tagging all of the files of the product that is in the older CM system immediately after the check-in with a tag that matches the SHAID hash of the corresponding git commit (reachable by typing
This allows you to have a one to one record for a set of files that correspond to a specific git commit.
Thanks for git’s flexibility we have found the answer! The solution has its own drawbacks, but it works.
The idea is simple. All
production-ready changes will be tracked in separate branch and files will appear there not via merge with development branch, but via checking out only required files from it.
Despite we’re loosing all pre-
production-ready history we’ll receive clean and simple way how to retrieve all
production-ready files in one go.
In our defense I might add, that this history issue could be leveled by adding to the commit message in
pre-production branch id of the commit from which file was checked out. And it is also possible to simplify the process by writhing simple git command that will perform series of needed commands.
These commands are:
git checkout pre-production
to switch to the
git checkout development file/name
to checkout needed file from
git commit -m "Moving file/name to pre-production from commit id 5364afb23"
to commit and label the movement.