ゼファーネットのロゴ

医療機器ソフトウェアを改善するための 3 つの Git ヒント

日付:

Git Tips 医療機器医療機器ソフトウェアは非常に多様です。低レベルのファームウェア ドライバーからデータ分析や AI、Web 開発やサイバーセキュリティに至るまで、テクノロジーは多岐にわたり、それぞれに独自の特徴があります。
このようなさまざまなテクノロジーの中で、1 つのテクノロジーが広く普及しています。それが Git です。バージョン管理システム (VCS) は常にそこにあり、それを実際に理解するために少し時間をかける価値があります。基本を超えて進めれば、Git はトレーサビリティを犠牲にすることなく、医療機器ソフトウェアをより迅速に開発するのに役立ちます。

医療機器ソフトウェアには、通常のソフトウェアのベストプラクティスを超えた追加の説明責任が必要です。 1 つの例は、構成管理と、ソフトウェアのバージョン間で何が変更されたかの記録の維持に関連しており、これはソフトウェア開発の明確な履歴を維持することを意味します。

Git を最大限に活用するには、Git の仕組みに関する独自のメンタル モデルを作成するのに少し時間を費やす必要があります。 Git をより良く使用するのに役立つ 3 つの目を見張るような気づきを見ていきましょう。

  1. すべてをコミットする必要はありません。

最良の状態では、Git は邪魔にならないのです。プログラマーとして私が望んでいる場所は「コード モード」です。そこでは時間を忘れて新機能やバグ修正、あるいはその両方をハッキングしています。ここでは、コードを作成することと、将来のレビュー担当者のために賢明な履歴を構築することの間に緊張関係があります。最も避けたいのは、プログラミングを中断して VCS について考えたり、レビュー担当者が変更をどのように探すか考えたりすることです。結局のところ、コミットを小さく自己完結型にすることが良い習慣となります。

プログラミングに夢中になり、まったくコミットせずに無関係な変更をいくつか加えたとします。職業はなんですか? Git は、ローカルのコミットされていないすべての変更が存在する「作業コピー」を、「ステージング領域」から分離します。 加えます コミットしたい変更。

以下の例は、SPI ドライバー、ディスプレイ ドライバー、およびいくつかのビジネス ロジックを使用してプロジェクトで作業するときにステージング領域を使用する方法を示しています。おそらくソースは次のように構成されています。

|– ドライバー/
| |– spi.c
| |– spi.h
| |– 表示.c
| |– 表示.h
|– アプリ/
| |– アプリ c
|– …

あなたは SPI ドライバを楽しく構築していましたが、その途中で、ディスプレイ上でページをよりスムーズにレンダリングするためのアイデアを思いつきました。ディスプレイ ドライバーにいくつかの変更を加えると、spi.c と display.c の両方に変更が加えられます。すべてを一度にコミットすると (「git add .」)、関連性のない変更が混乱することになり、git の衛生状態が良くありません。ディスプレイ ドライバーを賢く使おうとしてバグが発生した場合はどうなるでしょうか?削除されないようにするには、このパッチを元に戻してから、SPI にのみ関連する部分を選択する必要があります。ぎこちない!

代わりに、Git の強力な機能を使用してください ステージングエリア 作業コピーからアトミックな変更を取り出します。最初に SPI に関連する変更のみを追加し、それらをコミットすることで、 その後 ディスプレイ ドライバーの変更を追加すると、独立した優れた 2 つのコミットが作成されましたが、それらは同じ作業コピーからのものです。

git add Drivers/spi.c
gitコミット…
git add Drivers/display.c
gitコミット…

次のコミットが何になるかを考える必要がないことに注目してください あなたが変更を加えます。代わりに、後でコーディングに戻って、変更内容からコミットをビルドできます。 Git は、プログラミングに迷っても罰しません。カフェインを大量に摂取したバグ修正セッションの後に、必要な部分を見つけるのに役立ちます。

アトミックな変更が個々のファイルにローカライズされている場合、独立した変更を別のコミットに組み込むのは簡単です。しかし、app.c に適用される変更があった場合はどうなるでしょうか。 両言語で SPIとディスプレイの変更?もう一度言いますが、Git がそれをカバーします。

  1. –patch を使用して個別の変更を追加する

ステージング領域について学ぶことは別のことですが、ステージング領域からの変更をフィルタリングできることを理解することは別のことです。 単一ファイル内で 新しい能力の世界を開きます。 「git add」コマンドには「-patch/-p」オプションがあり、渡されたファイルをハンクごとに調べて、コミットに必要なものだけを取り込むことができます。追加を行ったり、提供されたハンクを分割したり、編集して行を手動で選択したりすることで、非常に具体的なものにすることができます。コミットをハンクごとに構築すると、変更が記憶に新しいので、より良いコミット メッセージを作成できる可能性が高くなります。

ヒント: 「singleKey」設定オプション ハンクのナビゲーションを高速化します (git config –global interaction.singleKey true)。これを機能させるには、Term::ReadKey モジュールが必要です。

「–patch」オプションは、「add」だけでなく多くのコマンドで使用できます。ファイルから特に受動的で攻撃的なコメントを 1 つ放り込みたいですか? 「gitreset –patch」!それとも、後で使用するために 1 ~ 2 行だけを隠し場所に保存したいですか? 「git stash -patch」!

  1. Gitの歴史

「歴史は私に親切にしてくれるでしょう、私はそれを書くつもりなのですから。」

  • 次の PR を開始するあなた

アトミック コミットを簡単にまとめられるようになったので、Git 履歴で伝えているストーリーの全体像を確認できるようになります。たとえば、ソフトウェアに新しい機能を組み込む際のよくある「2 歩進んで 1 歩戻る」パターンで、数日間新機能の開発に取り組んできたとします。

コードベースに新しいモジュールを導入しましたが、誤って別の場所でバグを引き起こしてしまいました。したがって、このバグを修正してコミットします それらの 変化します。新しいコードを導入してから、以前に導入したバグやリグレッションを修正するというこのパターンは、しばらく続きます。最後に、すべてのパッチを修正し、ピカピカの新機能を「メイン」ブランチにマージして戻す準備が整いました。

おそらく、機能ブランチは次のようになります。

$ git log –oneline –graph feature_branch
* (feature_branch) 境界ケースの問題を修正しました。
* ディスプレイドライバーをリファクタリングします。
* ページごとのレンダリングの改善。
* ディスプレイはページごとにレンダリングします。
* (主要) …

このブランチをマージすると、このすべての履歴が一緒に引き継がれます。それが歴史だ 誰も気にしません。 5 年後にプロジェクトの歴史を振り返ると、あるコミットで導入され、次のコミットで修正されたバグなど誰も気にしなくなります。開発中はこれらのコミットをチェックポイントとして扱いますが、すべてが機能するとすぐに、どのようにしてそこに到達したかを思い出す必要はなくなります。レビュー担当者は、おそらく間にいくつかの重要なマイルストーンを挟んで、プロジェクトを機能前から機能後まで移行させる最小限の変更セットを確認したいだけです。それで、これにどう対処しますか?機能が 100% 作成されて動作するまで何かをコミットするのを待つこともできますが、開発の途中ではそれが危険な状況になります。

Git は「git rebase –interactive」で再び役に立ち、ユーザーがコミット履歴を対話的に編集できるようになります。履歴からコミットを並べ替え、編集、削除、または「潰す」ことができます。インタラクティブなリベースに注意してください Git 履歴を変更する。そのため、非常に危険な可能性があります。注意しないと、ここでリポジトリに重大な損傷を与える可能性があります。

「dev/*」のようなテンプレートに一致するブランチ上の開発者に「巻き戻し」権限のみを許可するように git リモート ホストを設定することをお勧めします。これにより、開発者が何をしても、メイン ブランチやその他の重要なチェックポイントがそのまま維持されます。私のプロジェクトでは、「巻き戻し」は「tmp/*」と「dev/*」に一致するブランチでのみ許可されます。変更が共有機能ブランチまたは「メイン」に適用されると、履歴は変更されなくなります。可能であれば、受け入れられたプル リクエストからのものでない限り、「メイン」ブランチへのプッシュを禁止することで、このアイデアを論理的な結論に導きます。

サンプルの機能ブランチをもう一度見てみると、クリーンアップ後の履歴は次のようになります。

$ git rebase –interactive main..feature_branch
$ git log –oneline –graph feature_branch
* (feature_branch) ディスプレイ ドライバーをリファクタリングします。
* ディスプレイはページごとにレンダリングします。
* (主要) …

2 つのバグ修正コミットは親コミットに押し込められました。これにより、機能開発エラーのノイズがなく、コードベースに導入された新機能を明確に示すきれいな履歴が作成されます。

信頼できる履歴を保存することが VCS を使用する理由の 62304 つであり、構成管理は医療機器ソフトウェアに対する IEC XNUMX の重要な要件です。インタラクティブなリベースを使用すると、履歴が明確になり、XNUMX つのリリース間でソフトウェアがどのように進歩したかを簡単に確認できます。

まとめ

明確な履歴を維持することは、医療機器ソフトウェア開発の重要な側面です。医療機器製品向けのエキサイティングで広範な機能を開発する場合、Git の強力なステージング領域とインタラクティブなリベース機能により、作業を迅速に進め、中断を少なくすることができます。

画像:Adobe Stock

リーバイ・パケットは、 ソフトウェアエンジニア スターフィッシュメディカルにて。電気工学の学位を取得した彼は、エレクトロニクスと高品質の組み込みソフトウェアの間のギャップを埋めています。 Levi は、あらゆるレベルの医療機器ソフトウェアに携わっており、企業が新しい医療機​​器向けに効果的で革新的かつ安全なソフトウェアを開発できるよう支援しています。



これを共有…

スポット画像

最新のインテリジェンス

スポット画像