I got used to the following approach on bugfixing phase of the project development. The developer should add SVN commit number as a comment to the JIRA issue when resolving it. Latest artifact from CI-server shows build number which include major version, branch name and commit number. This approach helps QA easily to identify whether the bugfix was included in the latest build or not. Even when same issue was reopened and fixed again.
After moving from SVN to Git we lost incremental commit number. It is possible to solve this problem with tagging the code but tags are tied to the sprint numbers. And in case of the issue reopening this approach moves this issue resolving on the next sprint. But client is dissatisfied with the fact of having certain issue unfixed for a several sprints.
So, how do you identify bugfix commits in for QA environment?
Thanks.
UPD: The question is NOT about linking issues to commits, but about ability of QAs figure out whether certain fix (ticket) is included in certain build just by looking on build number and ticket comments.
12
How about using tags to mark the commits ?
See this post about another user moving from SVN to GIT and facing similar issues to you, e.g. “As the svn revisions are simple numbers we can use them to extend the version numbers of our plugins and SDK builds”
More info at How do you achieve a numeric versioning scheme with Git?
2
You might want to flip around the work flow here — rather than making the devs visit a different system to note commit numbers you can have the tracking system pull references out of the commit messages — JIRA supports specially formed comments that do just this. See this page to get started.
The general command that immediately jumps out at me is git branch --contains. Obviously that needs to be checked explicitly rather than at a glance.
But as long as you have at least one tag in your entire history and keep your history largely free of rebases, git describe --tags will give you a linear version.