開発ライフサイクルにおける GitHub の位置づけ

学習の目的

この単元を完了すると、次のことができるようになります。

昨今の開発者のツールキットに欠かせないツールを挙げる。
ソフトウェア開発ライフサイクル (SDLC) 内で Git と GitHub がどのように連携するかを説明する。
ソフトウェア開発エコシステムの中核をなす GitHub の位置づけを説明する。

GitHub アイコン

Git と GitHub の違い

Git と GitHub は名前も目的も共通していますが、同じものではありません。Git と GitHub を明確に区別するには時間が必要かもしれませんが、それでも大きな問題はありません。前の単元でもそれぞれを紹介しましたが、ここではこの 2 つがどのように連動するのかを詳しく見ていきます。

Git はバージョン管理アプリケーション

簡単に言うと Git は、プロジェクトの経時的な変更に関連するあらゆることを追跡するアプリケーションです。では、用語の定義から始めましょう。

リポジトリ: プロジェクトのコンパイルに使用するソースファイルのコレクション。
コミット: 特定の時点に存在したプロジェクトのスナップショット。プロジェクトの作業中に、個々の作業単位を追加または削除した時点を示すコミットを作成します。
ブランチ: プロジェクトの経時的な変更を示す一連のコミット。どのリポジトリにもデフォルトブランチがあり、コードの本番対応バージョンが含まれています。新機能の構築時、バグの修正時、プロジェクトへのその他の変更時などには、ブランチを新たに作成します。これらのブランチによって、実験的なコードがテスト済みの本番コードから隔離されます。
マージ: 2 つ以上のブランチを結合した履歴。通常は、機能を本番環境に移行するために、リポジトリのデフォルトブランチまたはリリース済みブランチに機能ブランチをマージします。
タグ: 特定のコミットへのポインターであり、イベントを永続的に参照します。一般にタグは、アプリケーションがリリースされた時点を示すセマンティックバージョン管理で使用されます。

GitHub はコラボレーションプラットフォーム

GitHub は、Git リポジトリのホストであり、変更をコードに適用してテストするコラボレーション機能を備えています。Git において GitHub は、リモートリポジトリとして機能します。これによって開発者は、共同作業用の信頼できるソースにアクセスできます。リポジトリのあらゆる Git データにアクセスできる GitHub に関しても、独自の重要な用語が存在します。

イシュー: プロジェクトについて相談したり、新機能の計画を立てたり、バグについて話し合ったりすること。イシューはディスカッションに過ぎず、ここで実際のコードに変更が加えられることはありません。
プルリクエスト: デフォルトブランチへのマージを依頼するコミットのパッケージ。プルリクエストは、提案する変更について話し合ったり、他のチームメンバーにコメントやコードレビューを依頼したりするための場となります。また、プルリクエストで、自動テストやその他のさまざまな素晴らしいインテグレーションの結果を確認できます。

GitHub は、開発者が最高の仕事を遂行できるように、透過性に優れたコンテクスチュアルな環境として設計されています。

まとめると、Git はバージョン管理に対応し、GitHub はコラボレーションに対応しています。

昨今の開発者のツールキット

Git と GitHub は連動して、昨今の開発者が利用するツールキットの中核を成しています。Salesforce アプリケーションと同様に、何百人ものインテグレーターが、ユーザーの意向に応じて GitHub の機能をカスタマイズおよび拡張できるツールを開発しています。プロジェクト管理、継続的インテグレーションのテスト、リリース、コードレビューなど、重要なタスクを担うこのエコシステムは増大しています。開発者は GitHub を毎日使うかもしれませんが、かといって、このツールだけを使う可能性は低いものと思われます。

GitHub を新しい Salesforce Developer Experience (DX) に統合することは難しくありません。Salesforce DX は、チーム開発やコラボレーションの向上から、自動テストや継続的インテグレーションの促進、リリースサイクルの効率化やアジャイル化まで、開発ライフサイクル全体を合理化する新しいツールセットです。また、信頼できるソースを組織からバージョン管理システム (VCS) に移行する、最新の開発パラダイムでもあります。GitHub には VCS などのさまざまな機能があるため、役立つ可能性があります。Salesforce DX についての詳細は「Salesforce DX を使用したアプリケーション開発」モジュールを参照してください。

以下に、注目すべき例をいくつかご紹介します。

GitHub には変更を加えるための簡易な UI が含まれていますが、大半の開発者は統合開発環境 (IDE) でローカルに作業することを好みます。Sublime Text、VSCode with Salesforce Extensions (VSCode 用 Salesforce 拡張機能) など、最新のテキストエディターは、簡単なテキスト編集機能に、ワークフローを拡張およびカスタマイズする何千ものユーザー作成パッケージを組み合わせるという同様のアプローチを採用して、広く普及しつつあります。

ワークフローに追加できるツールの中でも特に強力なものとして、継続的インテグレーション (CI) および継続的リリース (CD) アプリケーションが挙げられます。こうした CI および CD を GitHub と連携させることで、リポジトリに格納されている仕様を基にしてプロジェクトのテスト、ビルド、リリースを実行できます。こうしたインテグレーションにより、手動テストにかかる時間やストレス、「私のマシンでは動作するのに」といった不整合性、他の人に簡単なレビューやテストをしてもらう間の待ち時間を削減できます。

また、GitHub と連携できるその他のインテグレーションは、コード品質チェックツールや連動関係管理、さらには自動セキュリティチェックなど、無数に存在します。GitHub の API や Web フックを使用すれば、新しいインテグレーションを開発者が必要とする方法で追加およびカスタマイズできます。

ニーズに応じたワークフローのカスタマイズ

無限とも思われる選択肢がある GitHub は、各自のプロジェクトの細かいニーズや好みに合わせてカスタマイズできます。GitHub の組み込みプロジェクトのような、コンパクトなプロジェクト管理ソリューションを好む場合でも、ZenHub インテグレーションのような、フル機能のものを好む場合でも、GitHub エコシステムの豊富なオプションがそれに対応します。次の単元では、GitHub の基本的なフローについて説明します。それをどう活用するかはあなた次第です!