3

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.

Improve this question
12
  • 2
    "developer should add SVN commit number as a comment to the JIRA issue" -- why so? I ask because FishEye links commit to JIRA issue automatically when commit message refers that issue (if memory serves it can do so for SVN, Git, Perforce etc)
    – gnat
    Sep 26, 2014 at 8:32
  • As for the FishEye, company (or financial folks) can be against spending money on license for some software products which are not obviously effective from their point of view. As for the linking the issue to the commit, QA deal only with application. But even if they are familiar with FishEye and it is correctly set up and they see commits linked to the issues it doesn't help to tell whether the build contains certain fixes or not. It just points to the fact that certain fix was commited by developer.
    – igorp1024
    Sep 26, 2014 at 8:59
  • I see, thanks. Consider editing the question to clarify this for other readers
    – gnat
    Sep 26, 2014 at 9:00
  • 1
    Paste the commit hash and/or commit message into the tracker? This is just about indicating when something is done with a papertrail, right?
    – Weaver
    Sep 26, 2014 at 11:32
  • 1
    I place my jira bug id# in the commit message when I interactively rebase my commits. This is what I mean by workflow.
    – Michael Durrant
    Sep 26, 2014 at 17:40

3 Answers 3

Reset to default
2

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?

Improve this answer
2
  • Yes, right. But this means that single issue may be resolved only once per tag and tag is usually tied to the sprint. So this means that it is not possible to reopen (and fix again) showstopper within same sprint.
    – igorp1024
    Sep 27, 2014 at 19:11
  • 1
    @igorp1024 Why can't you have multiple tags per sprint? Have a tag per major build; I assume your build numbers increase monotonically? Say, I've built something from a commit I remember; after the build is done, I might git tag that commit with the build number. Maybe your build system can do this automatically. Tie fixes to builds / tags, not to commits. Tags are very cheap. Just clean them up on the next sprint.
    – 9000
    Oct 27, 2014 at 18:49
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.

Improve this answer
0

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.