{"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":"
<\/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 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 |\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 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 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\n
\n