{"id":486674,"date":"2024-01-15T18:36:19","date_gmt":"2024-01-15T23:36:19","guid":{"rendered":"https:\/\/platohealth.ai\/3-git-tips-to-improve-medical-device-software\/"},"modified":"2024-01-15T21:32:05","modified_gmt":"2024-01-16T02:32:05","slug":"3-git-tips-to-improve-medical-device-software","status":"publish","type":"post","link":"https:\/\/platohealth.ai\/3-git-tips-to-improve-medical-device-software\/","title":{"rendered":"3 Git Tips to Improve Medical Device Software","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
\"GitMedical device software is very diverse. From low-level firmware drivers to data analysis and AI, to web development and cybersecurity, the technologies are wide ranging, each with their own quirks.<\/h5>\n
In all this variety, one technology is ubiquitous: Git! Your version control system (VCS) is always there, and it\u2019s worth taking a bit of time to really get to know it. If you go beyond the basics, Git will help you develop medical device software faster without sacrificing traceability.<\/h5>\n

<\/span><\/p>\n

Medical device software requires extra layers of accountability above and beyond the usual software best practices. One example is related to configuration management and maintaining a record of what changed between software versions, which implies keeping a clear history of the software\u2019s development.<\/p>\n

You need to put in a bit of time to make your own mental model for how Git works to make the most of it. Let\u2019s dive into three eye-opening realizations which help me use Git better.<\/p>\n

    \n
  1. You Don\u2019t Have to Commit Everything!<\/strong><\/li>\n<\/ol>\n

    At its best, Git gets out of the way. The place I want to be as a programmer is in \u201ccode mode\u201d \u2013 where I lose track of time hacking away at a new feature, or bug fix, or maybe both. There is a tension here between getting the code written and building a sensible history for future reviewers. The last thing I want to do is interrupt my programming to think about VCS and how changes are going to look for a reviewer. After all, it\u2019s good practice to make commits small and self-contained.<\/p>\n

    Say you get carried away programming and made a couple unrelated changes without committing any of them. What do you do? Git separates the \u201cworking copy\u201d \u2013 where all local, uncommitted changes are \u2013 from the \u201cstaging area\u201d \u2013 where you add<\/strong> changes you want to be committed.<\/p>\n

    Here\u2019s an example to illustrate how to use the staging area when working on a project with an SPI driver, a display driver, and some business logic. Maybe the sources are organized like this:<\/p>\n

    \n
    \n

    |\u2013 Drivers\/<\/p>\n

    |    |\u2013 spi.c<\/p>\n

    |    |\u2013 spi.h<\/p>\n

    |    |\u2013 display.c<\/p>\n

    |    |\u2013 display.h<\/p>\n

    |\u2013 App\/<\/p>\n

    |    |\u2013 app.c<\/p>\n

    |\u2013 \u2026<\/p>\n<\/div>\n<\/div>\n

    You have been happily building out your SPI driver, but on the way, you have an idea for rendering pages more smoothly on your display. You drop in a few changes to your display driver, and now you have changes in both spi.c and display.c. If you commit it all at once (\u201cgit add .\u201d) then you\u2019re tangling up changes that aren\u2019t related, which isn\u2019t good git hygiene. What if you introduced a bug while trying to be clever with your display driver? You\u2019d have to revert this patch and then pick out the parts that are only related to SPI to save them from being dropped. Gnarly!<\/p>\n

    Instead, use Git\u2019s powerful staging area<\/strong> to tease out atomic changes from the working copy. By adding only changes related to SPI first, committing those, then <\/em>adding display driver changes,  you have created two commits which are nice and independent, but which come from the same working copy!<\/p>\n

    \n
    \n

    git add Drivers\/spi.c<\/p>\n

    git commit \u2026<\/p>\n

    git add Drivers\/display.c<\/p>\n

    git commit \u2026<\/p>\n<\/div>\n<\/div>\n

    Notice how you don\u2019t have to think about what your next commit will be before <\/em>you make the changes. Instead, you can get back to coding and build commits from your changes later! Git doesn\u2019t punish you for getting lost in the programming; it helps you pick up the pieces after a caffeine-fuelled bug fixing session.<\/p>\n

    When the atomic changes are localized to individual files, teasing independent changes into different commits is easy. But what if there are changes in app.c which apply to both<\/em> SPI and display changes? Once again, Git has it covered.<\/p>\n

      \n
    1. Adding Individual Changes With \u2013patch<\/strong><\/li>\n<\/ol>\n

      Learning about the staging area is one thing, but realizing that you can filter through changes from within a single file<\/em> opens a new world of capability. The \u201cgit add\u201d command has a \u201c\u2013patch\/-p\u201d option which takes you hunk-by-hunk through the files you\u2019ve passed to it, letting you pull in only what you need for the commit. You can get very specific with additions, splitting provided hunks and even hand-picking lines by editing them. A bonus of building commits hunk-by-hunk is that you\u2019ll probably write a better commit message, because the changes will be fresh in your mind.<\/p>\n

      Tip: use the <\/em>\u201csingleKey\u201d config option<\/em><\/a> to make navigating hunks faster (git config \u2013global interactive.singleKey true). You\u2019ll need the Term::ReadKey module for this to work.<\/em><\/p>\n

      The \u201c\u2013patch\u201d option is available on more commands than just \u201cadd\u201d. Want to toss one particularly passive aggressive comment from a file?  \u201cgit reset \u2013patch\u201d! Or want to save just a line or two to your stash for later? \u201cgit stash \u2013patch\u201d!<\/p>\n

        \n
      1. Git History<\/strong><\/li>\n<\/ol>\n

        \u201cHistory will be kind to me, for I intend to write it.\u201d<\/em><\/p>\n