I'd like to re-emphasise Jason's excellent comments, below:

From: "Jason Pyeron" <>
From: agi
Sent: Tuesday, June 17, 2014 10:58

Hi Jason,

Thanks for the speedy reply. We are in the process of trying
to make our
software product ISO13485 compatible and we are assessing all systems
that we use.
Do you have a validation document for git that could provide
on how to use it in order to comply with ISO legislations?

That would be customized to your QA process. A generalized document would be too
vague. I am sure any process consultant could draft that up for you.
(disclaimer: I have been paid to do things like this before)

Maybe you could start by searching with things like or contacting Atlassian about
their QA product suite integration with Git.

Maybe you could find a process consultant to do it cheaper if you release it out
to the FOSS community?

The "nice" (read as less effort) thing about ISO 13485 is it:
*     does not have a continual improvement requirement
          so as long as "defects" are detected and
            remediated you are good.
That detection is part of your wider QA system.

Please note:
*     git does not detect defects,
*     git does not remediate defects.

That's not the job of Git (or any version control system and it's repository).

What git does is:
*     ensure the approved artifact is unchanged in any attribute
       to maintain the exact level of quality from first inspection
      of that artifact for an unlimited amount of iterations.
* Git has built in "digital signatures" on the artifacts stored in its repository.

These are the big points. The fact that everything is fully 'signed' by the sha1 and can't be altered is the guarantee that runs all the way up and down the git commit heirachy. If you have the same sha1 you have the same (identical, byte for byte) history - fsck will check all the way down to the very first entry.

You can also tag specific points as formal releases to simplify the association of a nice name to a specific sha1. The releaser can even gpg sign it.

You still need to ensure you take formal backups and archives in the usual way, though Git gives you extra security because of the implicit duplication among developers, readers and contributors.

As an aside, branching[1] allows developers to still tidy up their work (rebase etc) before it is accepted as part of the release software. That work still has its sha1 signatures, whether for the prior 'ugly' work or new sha1 signatures for the 'tidy' work that is / hopes to be incorporated into the release.

Any additional information or material you can think of is more than

Thanks in advance for your help!

Best Regards,
Agnes Pasztor

Senior Test Engineer
Omixon Biocomputing Ltd.

On 06/16/2014 05:20 PM, Jason Pyeron wrote:
>> -----Original Message-----
>> From: agi
>> Sent: Monday, June 16, 2014 11:14
>> Hello,
>> I would like to ask a question about GIT v. 1.7
>> Is it compatible with ISO 13485 (quality management system)?
>> Can it be
>> used for developing a medical diagnostic software?
> Yes.
> Now, do you have a specific question about how to use Git
in your QA process?

-                                                               -
- Jason Pyeron                      PD Inc. -
- Principal Consultant              10 West 24th Street #100    -
- +1 (443) 269-1555 x333            Baltimore, Maryland 21218   -
-                                                               -
This message is copyright PD Inc, subject to license 20080407P00.

[1] Branching is part of the strength of Git's "DAG" (Directed Acyclic Graph) structure.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to