It enables linking commit with tasks thanks to a special mark-up tag that developers have to add to their commit message.
Such link provides traceability between code modifications and tasks, which is nice. Even further, it provides traceability between code modifications and the business items that required them (commits are indeed displayed on stories, aggregated from their tasks). Thus, it makes it possible for someone, e.g. a developer, to know what business need lead to modifying a specific piece of code.
The opens a new perspective that I did not think about up-to-now. Thank You!
Actually I thought about something simpler, eg I want to return to the exact same project state before the start of the sprint planning if something goes wrong during the sprint planning.
In my naive approach I would export the project into the XML file, would add and commit it to a git repository with a meaningful comment,on the command line and then if something goes wrong import it again.
So I ask now: Are there a kind of convenient functions which support this kind of work?
Oh I see, I had a doubt when answering your first question.. it seems we are not talking about the same thing! Your question was about versioning of iceScrum items, whereas I answered about the link between code versioning in Git/SVN and iceScrum items.
Can you provide a simple example of what could go wrong and would require a full rollback, just to be sure that I understand your needs?