Altium Designerを使用したハードウェアのためのGit入門

Davide Bortolami
|  投稿日 九月 29, 2020  |  更新日 十月 4, 2020
Altium Designerを使ったハードウェアのためのGit

はじめに

数年前、私は一時的にヒップでカフェインたっぷりのスタートアップ環境から、より経験豊富な企業でのエンジニアリングの仕事に移行しました。その時、技術文化とツールとの二項関係に気づきました。私たちの考え方や働き方は、私たちが利用可能なツールによって形成されます。なぜなら、私たちのニーズや習慣が私たちが選ぶツールに影響を与えるからです。

私が働いていた新しい会社は、3Dプリンターや自社製バグ追跡ソフトウェア、良質なCMSに慣れていませんでした。全てがかなり古風でした。これは、私と同僚が日々作り出すものに大きな影響を与えました。

例えば、過去数十年で業界はTO220パッケージからD2PAKへと移行しました。同時に、エンジニアはJBCが製造するような高ピークパワーのはんだごてを装備しました。

設備の整ったラボを利用できる若いエンジニアが、この10年でTO220の一般的なICを考慮するでしょうか?そうは思いません。最新世代のはんだごてがあれば、D2PAKを扱う方がずっと簡単で、ネジやワッシャー、絶縁フォイルを扱う手間が省けます。この単純な変更により、エンジニアはよりフラットなボードの設計を目指すようになり、これは現代の基準によると、より美的に魅力的な製品につながることがよくあります。

Gitは、業界全体を一変させた珍しい例です。10年前、ソフトウェアエンジニアリングマネージャーは、素早く動いて物事を壊すアプローチを採用することを狂気と考えたでしょう。ハードウェアとPCB設計のためのGitにより、リビジョントラッキング、バージョン管理、および設計変更のロールバックが可能になりました。開発者は、Git blameという機能のおかげで、オープンソースプロジェクトへの努力が常に帰属され、検証されることを保証されています。10年前、オープンソースプロジェクトへの貢献が政治に委ねられていた時代がありました。これらはすべて、Gitのおかげで起こった変化の例です。

その本質により、電子業界はソフトウェアよりも遅く動きますが、多くの革新が私たちの日常業務に浸透しています。Altium Designer®は、今年Altium 365®とConcord Pro™の導入により、業界をリードしており、他の重要なプレイヤーは、10年以上前にリリースされた機能でさえ追いつくのに苦労しています。ハードウェアとPCB設計のためのGitは、その変化を推進する技術の一つです。

Gitとは何か?

非常に単純に言うと、Gitはバージョン管理システム(VCS)です。これは、ソフトウェア開発者がコード変更を追跡および管理するために使用するソフトウェア(プロトコルとデータ形式を含む)です。この10年でソフトウェア開発者であれば、デスクトップ上でフォルダを複製して試すのではなく、ほとんどの場合、Gitに基づいたVCSを使用しています。

Gitはソフトウェア開発でのコード変更の追跡に広く使われていますが、任意のファイルセットの変更を追跡するために使用することができます。これらのファイルにコードを含む必要はなく、PCB設計ファイル、設計文書、PCB製造ファイル、およびプロジェクトに必要なその他のファイルである可能性があります。ハードウェアのためのGitは、機械設計、PCB設計、ファームウェアなど、Gitエコシステムを自然に拡張したものです。

Gitは商用利用に無料で利用可能です。オープンソースであり、GNU General Public Licenseの下で配布されています。各Gitディレクトリは独立したエンティティであり、自身がリポジトリであり、そのアイテムの完全な履歴を含んでいます。Gitリポジトリに配置された各ファイルは、誰によって、いつ、どのビットまで完全に追跡可能です。Gitリポジトリはネットワークアクセスを必要とせず、各リポジトリはリモートと呼ばれるサーバーと完全に独立しています。

それ故、現在、世界で最も人気のあるVCSであることは驚くべきことではありません。ほとんどの市場シェア分析では、Gitが75%を超え、最も人気のある代替品であるSVNは2012年以降減少しています。SVNを必要とする求人(Altium DesignerもサポートするレガシーVCS)も減少している一方で、Gitは人気を集めています。

Gitの歴史

Gitは2005年にLinuxカーネルの開発者であり、伝説の人物であるLinus Torvaldsによって作成され、書かれました。Linuxコミュニティは、BitKeeperという商用ソフトウェアの無料使用を許可されていました。2005年4月、BitKeeperの作者は、Linuxチームの著名なメンバーであり、Sambaファイルサーバーの発明者であるAndrew Tridgellが、(おそらく)BitKeeperプロトコルをリバースエンジニアリングに基づいてオープンソースクライアントの開発を始めた後、ライセンスを撤回しました。BitKeeperライセンスはリバースエンジニアリングを明示的に禁じています。

したがって、Linus Torvaldsは、残りの代替品が彼の要件を満たすものではないと判断し、自身のバージョン管理システムを作成することにしました。それは、当時使用されていた人気のあるCVS(Concurrent Version Systems)とは非常に異なるものになることをTorvaldsは決定しました。彼は、現在のシステムではパッチを適用するのに長い時間がかかり、チームと同期する際に一度に数百のパッチを適用する必要があるため、そのパフォーマンスは受け入れられるものではないと認識しました。彼は一連の要件を考え出しました:

  • BitKeeperが可能にしたような分散型のワークフロー。ユーザーはオフラインで作業し、後で同期できるべきです。
  • データの破損などの事故から保護されること
  • 悪意のある攻撃から安全であること
  • 2秒未満でパッチを計算できること

Gitの開発作業は2005年4月初旬に始まりました。2005年6月16日には、ソフトウェアが急いで必要とされた理由であるLinuxカーネルのバージョン2.6.12がリリースされました。その後、Gitの開発とメンテナンスは、開発に貢献し、現在も貢献しているJunio Amanoに引き継がれ、ソフトウェアを使いやすくしたことで広く評価されています。Git 1.0は2005年12月にリリースされました。

命名規則

なぜGitか? 少なくとも奇妙な名前です!英国の多くの人々が知っているように、この用語はしばしばちょっと生意気な人、またはOxford Online Dictionaryによると「不愉快または軽蔑すべき人物」に与えられます。さらに報告された意味には、「愚か者」(18世紀から19世紀のスラング(英国))や「私生児」(18世紀半ばから19世紀のスラング(米国))があり、どちらも世界を変える芸術作品を創造するために隠れている孤独な天才の隠者の神話に詩的に適合します。

Torvaldsは、システムに「Git」という名前を付けた理由をいくつか挙げており、それはその日のユーザーの気持ち、またはシステムを書いているさまざまな時期に彼が感じていたことに基づいて選ばれると言います!彼は公式ドキュメントでしばしばそれを「愚かなコンテンツトラッカー」と表現し、Gitの定義を次のように述べています:

  • 「発音できない3文字のランダムな組み合わせ」。
  • 「get」の誤発音!
  • 計画通りに機能する場合はグローバル情報トラッカー
  • そうでない場合は愚かで、軽蔑すべき、そして卑劣なもの。

ああ、プログラマーのユーモア。

欠点

しかし、Gitには完璧ではなく、いくつかの欠点があります。理解しにくいデータ構造と奇妙な専門用語は間違いなくその中に含まれます。これには、同じファイル構造と操作が強制されるハードウェアプロジェクトのGitも含まれます。

Cherry-picking、Checkout、Index、Clone、Push、Stash、Pull/Pull Request、Tag、Upstream、Fork、Rebase、Origin、Fetch、そしてHEAD(常に完全な大文字で書かれています、なぜかは分かりません)など、ソフトウェア世界で見つけることができる最も奇妙な用語のいくつかです。

リポジトリをサーバーサイドソフトウェアとして設定する方法、ローカルリポジトリとリモートリポジトリの関係、およびそれらを同期させるための操作を理解するのは難しい場合があります。GitはSVNよりも学び、使用するのがはるかに複雑である部分的には、それがはるかに強力で効率的であるためです。

幸いなことに、Altium DesignerとConcord Proはこれらの問題のほとんどを解決します。コマンドラインを通じてGitの力を完全に活用できる一方で、Concord Proのユーザーインターフェースと厳格な統合が操作を簡単かつ直感的にします。同時に、Altium 365はすべてのサーバーサイドの問題を解決します。

ハードウェア用のGitはどのように機能するのか?

Gitは...非常に奇妙に感じることがあります!主に、従来のコピー&ペースト、圧縮、そして多くのエンジニアが慣れ親しんでいるメールとは大きく異なるワークフローを反映した専門用語があります。

ブランチング(およびマージング)

ブランチングモデルは、GitをSVNのような他のVCSと区別する最も人気のある機能の一つです。Gitには、ローカルおよびリモートの複数のブランチがあります。木の枝が幹や互いから分岐するように、Gitのブランチも他のブランチから発生します。木の「幹」、つまりメインブランチはmasterと呼ばれます。ブランチは簡単に作成、マージ、削除することができます。ここではこれらの操作がどのように機能するかです:

  • 各ブランチは独立しており、リモートで作業するときに他人の足を踏む必要はありません。自分自身で複数のブランチを持つこともでき、それぞれのブランチには自分のソフトウェアやハードウェア設計のわずかに異なるバリエーションが含まれており、ファイルを手動で閉じて再開することなく同じディレクトリ内で切り替えることができます。
  • ソフトウェアの世界では、masterと呼ばれる本番ブランチと、developと呼ばれる作業中のブランチを持ち、新機能や修正のために必要なだけ多くの小さなブランチを持つことが一般的です。同じアプローチはハードウェアプロジェクトにも適用できます。実際、ハードウェア専用のPCB設計などのプロジェクトを含む多くのGitHubリポジトリがあります。
  • すべてのブランチをmasterブランチにマージする必要はありません。開発者はしばしば、新機能がそれほど天才的な閃きではないと判断し、もはや必要ない場合には単にブランチを削除できます。

[オタクモード オン]

では、この賢い機能はどのように機能するのでしょうか?ブランチは本質的にコミットへのポインタです。コミットは、リポジトリにプッシュされたファイルの変更、追加、または削除のセットです。コミットには40文字の暗号学的SHA-1チェックサムがあり、ファイルに書き込まれます。各コミットには、それが発生した親コミットへのポインタも含まれています。

多くの追加の中間ステップがあります。たとえば、ファイルはチェックサム付きのバイナリブロブに変換され、バイナリツリーを通じてディレクトリに整理されます。ツリーのチェックサムも計算されます。すべてが暗号学的にハッシュされているため、最後のコミットのハッシュを変更せずにデータや履歴を変更(または破損)する方法はありません。暗号学的ハッシングにより、Gitの履歴はある程度永続的になるため、コミットメッセージを書くときは礼儀正しくしてください!

[オタクモード オフ]

ハードウェアのためのGitワークフロー

Git for hardwareの分散性と高度なブランチングシステム、およびその他の多くの機能のおかげで、ユーザーは任意のワークフローを採用する自由があります。

最も人気のある中で、*Centralised Workflow*モデルは、集中型バージョン管理システムの経験があり、初めてGit(*分散型*)を使用する人々がよく使用するものです。*Centralised Workflow*はほぼ完全にmasterブランチに依存し、すべてのコミットがプッシュされフェッチされることで、GitがSVNの動作やリモートファイルシステムを模倣するようにします。

フィーチャーブランチングワークフローは、*セントラライズドワークフロー*の進化形です。開発作業は別々のブランチで行われ、その後マスターにマージされます。私はこのモデルの熱心な支持者であり、Altiumがブランチサポートを発表し、それを活用できることを心待ちにしています。フィーチャーブランチの例には、「fix_current_generator_oscillation」、「upgrade_microcontroller」、「lower_power_consumption」、または「reduce_thermal_drift」があります。

将来のブランチを示唆
図1. AltiumはUIで将来のハードウェアブランチサポートを示唆しています。

GitFlowワークフローでは、人気のあるワークフローの中でおそらく最も複雑なもので、マスターブランチには完全な設計リリースのみが含まれます。これをboard_v_1.0、board_v_1.1などと考えることができます。開発はdevelopと呼ばれる別のブランチで行われ、フィーチャーと修正はdevelopブランチから派生します。準備が整ったら、developのみがマスターにマージされます。

分散化と速度

Gitはいくつかの理由で他のバージョン管理システムよりも速いです。各ユーザーは元のリポジトリをクローンでき、ローカルブランチに定期的にコミットを行い、リモートには頻繁に送信する必要がありません。分散化されていない他のVCSは、リモートサーバーの容量によって制限され、すべてのリクエストを満たすために大幅に遅くなる必要があります。

このローカルファーストのアプローチは、特に電子業界では非常に重要です。ファイルはかなり大きいことがあります。特に数百の3Dボディを含むPCB設計では、サイズが数十メガバイトになることは珍しくありません。一方、ソースコードファイルは最大でも数百キロバイトです。

私が以前勤めていた会社では、VPNを通じてアクセス可能な本社にホストされたSVNリポジトリがあり、そこにプロジェクトファイルとドキュメントを保存していました。操作を行うのに永遠に時間がかかり、限られたインターネット接続は頻繁に数千のファイルを管理するすべてのリクエストによって詰まっていました。

GitはC言語で書かれているため、他の高レベル言語と比較してオーバーヘッドが最小限です。操作によっては、GitはSVNよりも数倍から数百倍速い場合があります。

分散化されたオフラインファーストのアプローチは、Gitをネットワーク上で非常に軽量にします。会社がブロードバンドにアクセスできない場合でも、昼休みや仕事後にデータをプッシュでき、日常業務のパフォーマンスが低下することはありません。

Concord Proでは、インターネット接続にアクセスできるときにAltium 365のすべての利点を享受し、その後はAltium Designerライセンスをローミングしてオフラインで作業を続けることができます。

ステージングエリア

Gitを使用する際には、ファイルがバージョン管理下にあると真に考えられる前に、3つの段階を経ることを理解することが重要です:

  1. 未追跡
  2. ステージング
  3. コミット済み

未追跡は、ファイルがディスク上に存在するが、バージョン管理システムの外にある状態です。未追跡ファイルはその後、ステージングされることができ、これはバージョン管理システムに追加されたがまだコミットされていないことを意味します。この時点で、ステージングされた変更をコミットすることができます。ステージングシステムはコミットの準備のために使用されますが、この機能は主にコマンドライン操作で使用されます。

Altiumを通じてGitを使用する場合、操作を簡素化するグラフィカルユーザーインターフェースのおかげで、ステージングアプローチはサーバーに変更を保存するときに自動的にバックグラウンドで適用されます。

ハードウェア用gitでのファイルステージング
図2. コミットプロセスの一部として自動的に行われるファイルステージング。

リポジトリの作成

新しいプロジェクトを作成すると、リポジトリはサーバー側で自動的に作成されます。以下のウィンドウでは、Fermium LTDのワークスペース内でテンプレートから新しいPCBプロジェクトを作成しています。プロジェクトを作成するとすぐに、それは私のAltium 365ワークスペースでアクセス可能になり、プラットフォームは新しいプロジェクトのために自動的にGitリポジトリを作成します。

ハードウェア用gitの新規プロジェクトウィンドウ
図3. 新規プロジェクトウィンドウ。

リポジトリの初期設定

Concord Proで作成されたリポジトリは自動的に設定されるため、プロジェクトのGitリポジトリには必要なファイルのみが既にコミットされ、ローカルバックアップやLOGファイルは含まれません。通常は".Gitignore"というファイルを適切に設定し、不要なファイルをコミットしないようにする必要がありますが、Concord Proがそれを処理します。

ハードウェア用gitと最初のコミット
図4. 最初のコミット時には、リポジトリが既に設定されていることがわかります。

認証情報の設定

Gitリポジトリにアクセスするためには、一般的にサーバー側とクライアント側の両方でSSHキーとユーザー認証情報を設定する必要があります。Concord Proは、新しいユーザーが追加されたときにこれを自動的に処理します。

ハードウェア用gitで新しいユーザーを追加
図5. 管理インターフェースで新しいユーザーを追加しています。

リポジトリのクローン作成

クローン作成は、Gitがリモートリポジトリをローカルコピーに複製するプロセスです。PcbDocやSchDocファイルなどのバイナリファイルを含む大規模なリポジトリを手動でクローン作成するには、通常、Gitのコマンドライン操作の専門知識が必要です。Altium DesignerとConcord Proは、リモートプロジェクトを開くと、バックグラウンドで自動的にリポジトリをローカルマシンにクローンします。

コンフリクトの解決と変更の比較

Concord Proでは、ストレージマネージャーパネルを通じて、ローカルとリモートの異なるリビジョン間の変更を比較することができます。次の例では、テキストノートオブジェクトを追加し、ローカルに変更をコミットしましたが、リモートにはプッシュしていません。

ハードウェア用gitでドキュメントリビジョンを追跡
図6. 現在のドキュメントリビジョンとリモートバージョンを比較しています。

これにより、ハードウェア用Gitプラットフォームに必要な機能がすべて揃います。

結論

Gitは強力なツールであり、ハードウェア用GitはPCBデザイナーにバージョン管理、共有、リビジョン管理のための包括的なワークフローを提供します。この人気のあるシステムは、現代のプログラマーの文化を形成するのに役立ちました。現在、Altium Designer®とAltium 365®プラットフォームを使用すると、デザイナーはPCB設計のためのGit機能にアクセスできます。

本日からAltium 365のトライアルを開始し、例示プロジェクトが満載の21世紀スタイルの電子開発を完全に体験してください。さらに質問がありますか?今すぐAltiumの専門家に相談してください

筆者について

筆者について

David BortolamiはPCBおよび回路設計について幅広い知識を持つ電子機器技術者です。現在、世界で最も先進的な教育用、および研究用科学装置を製造しているイギリスの小さな企業、Fermiumの代表です。

「どんな製品だって、コストを半分に下げ、品質を2倍に上げて作ることができます。肝心なのは、なぜ、その製品が存在するべきなのかを考え抜き、それ以外の部分を取り除くことだけです。」

Davidは、起業家としてEMC規制要件を満たす工程の中で、製造や統合電子機械製品の設計に関するあらゆるハードルに直面してきた経験があります。過去には、イタリア最大のファブラボ/ハッカースペースCowingsを運営し、電子インバータなどのEMI重工業に特化した企業のPCBエンジニアリングも担当していました。

Davidと直接やり取りする場合の連絡先: d@fermium.ltd.uk

関連リソース

関連する技術文書

ホームに戻る
Thank you, you are now subscribed to updates.