Skip to main content
Build the future with Agentforce at TDX in San Francisco or on Salesforce+ on March 5–6. Register now.

GitHub 内でのコラボレーションの模索

学習の目的

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

  • コラボレーションを促進する組織構造を構築する。
  • 頻繁にアクセスする GitHub リポジトリのセクションを挙げる。
  • GitHub にソースコードと共に表示されるコラボレーション機能を説明する。

GitHub ロゴ

GitHub リポジトリのツアー

Git コマンドを実際に使用してみる前に、GitHub の構造と、チームのコラボレーションにどのように役立つのかを見ていきましょう。

リポジトリは GitHub のごく基本的な要素です。プロジェクトフォルダーを思い浮かべるとわかりやすいでしょう。ラップトップ上の通常のフォルダーと異なる点は、GitHub リポジトリには、他の人々とコラボレーションするためのシンプルで強力なツールが備わっていることです。

リポジトリには、プロジェクトに関連する全ファイル (ドキュメントを含む) が格納され、各ファイルの変更履歴が保存されます。GitHub に興味があるだけという人にとっても、中心的なコントリビューターである人にとっても、リポジトリの操作方法を把握しておくことは不可欠です。

新しいリポジトリページを作成して、[Repository Name (リポジトリ名)] に「hello-world」、[Description (説明)] に「Just another repository」(もう 1 つのリポジトリ) と入力します。このリポジトリは [Public (パブリック)] と [Add a README file (README ファイルを追加)] に設定されています。

GitHub 組織の設定

効率的に計画を立てるための第一歩は、各人の役割を理解することです。GitHub にチームや組織を設定すれば、コラボレーションをスムーズに進めることができます。

GitHub にサインアップすると、ユーザーアカウントが自動的に作成されます。ユーザーアカウントの権限はごくシンプルで、他のユーザーを特定のリポジトリのコラボレーターとして追加するだけです。 

組織アカウントでは、リポジトリ権限をいっそう綿密に制御できます。この場合は、ユーザーのチームを作成し、続いてそのチームに特定のリポジトリへのアクセス権を付与します。権限 (参照、更新、管理者など) はチームレベルで割り当てることができますが、ユーザー単位で割り当てることも可能です。

チームは GitHub の強力な機能であり、社内での実際のチーム編成に基づいて構成することも、ユーザーに指定されたロールとは関係なく、スキル、関心事、専門知識に即した特殊な構成にすることもできます。

GitHub のリポジトリには大量の情報が格納されています。最初に注目すべき重要なセクションは、コード、イシュー、プルリクエスト、アクション、プロジェクトです。

リポジトリのコード

コードビューには、リポジトリに格納されているファイルが表示されます。プロジェクトコードやドキュメントをはじめとする重要なファイルです。このビューはプロジェクトのルートともいいます。Git のバージョン管理でこうしたファイルへの変更が追跡されます。

リポジトリにアクセスすると、コードビューにデフォルトブランチが自動的に表示されます。リポジトリを作成した時点でデフォルトブランチがメインになりますが、必要に応じて別のブランチをメインに変更できます。また、ドロップダウンでブランチを選択すれば、リモートにプッシュ済みのブランチを表示できます。

[Branch (ブランチ)] ドロップダウンを選択し、[Switch branches/tags (ブランチ/タグの切り替え)] 項目に「readme-edits」と入力

イシューを使用したプロジェクトのディスカッション

イシューは、フォーラムのようなスレッド化されたディスカッションで、GitHub リポジトリに組み込まれています。イシューでバグや機能要求を追跡し、特定のチームメンバーにイシューを割り当てることができます。イシューの目的は、ディスカッションやコラボレーション、そしてコミュニティへの参加を促進することです。

シンプルかつコンパクトなイシューは、GitHub の他の強力な機能と併用することが意図されています。併用する場合はイシューに、他のイシュー、プルリクエスト、ラベル、マイルストーン、プロジェクトなどへのリンクが作成されます。

メモ

イシューは純粋にディスカッションの場です。イシューの結果として実際に変更されるものはありません。

プルリクエスト

プルリクエストとは 2 つのブランチの比較です。通常は、メイン (本番コードがあるブランチ) と、開発環境のコードに使用されている別のブランチを比較します。プルリクエストによって、コードへの変更が示されます。つまり、ブランチに実行したファイルの追加、修正、削除を、著者が (通常は本番コードの) 別のブランチに取り込む場合にプルリクエストを使用するものと考えられます。多くの場合、リポジトリに問題が生じるとプルリクエストで作業が行われます。

ファイルに実行された変更を示すスクリーンショット。

また、プルリクエストは 2 つのブランチ間の変更に関する会話の場でもあります。たとえば、Ali がバグを修正したところ、誤って別のバグを生み出してしまったとします。Sally がこの作業を参照し、新たな問題を知らせる簡単なコメントを (プルリクエストで) Ali に送信したうえで、この問題を自身で修正するか、マージする前に Ali がすぐ編集できるようにすることができます。

コミットのコード変更に関するディスカッションを示すスクリーンショット。

プルリクエストを使用すると、コードレビューが促進され、自動テストの状況が表示されるため、より良いソフトウェアを作成できるようになります。ここで覚えておくべきは、プルリクエストはコードを比較し、そのコードに関する会話のプラットフォームを提供し、徹底的なコードレビューを促進し、各種のインテグレーション (テストも含まれます) とシームレスに連動するということです。プルリクエストは、GitHub 上でコラボレーションすることの最も大きな利点の 1 つです。

アクション

GitHub アクションを使用すると、カスタムソフトウェア開発ライフサイクルのワークフローを GitHub リポジトリに直接作成できます。個々のタスク (アクション) を作成し、組み合わせてカスタムワークフローを作成できます。ワークフローは、リポジトリに設定できるカスタム自動プロセスで、GitHub のコードプロジェクトのビルド、テスト、パッケージ、リリース、展開を行うことができます。

GitHub の [Actions (アクション)] タブ

GitHub アクションを使用して、リポジトリに直接堅牢な CI/CD 機能をビルドできます。また、プッシュ、イシュー作成、新規リリースのような GitHub イベントに応じてワークフローを実行することもできます。

GitHub アクションでは、色と絵文字がサポートされたライブログで、ワークフローの実行をリアルタイムに確認できます。これにより、簡単に特定の行番号を指定して強調表示し、成功か CI/CD ビルドエラーかを共有できます。

プロジェクトを使用した作業の整理

イシューもプルリクエストも優れた機能であり、さまざまな形態のコラボレーションに多大なメリットをもたらします。この 2 つを統合した「プロジェクト」であれば、大規模な作業を直感的に追跡および計画できます。

GitHub の Kanban 様式のプロジェクトボードのスクリーンショット。

プロジェクトを使用すると、作業を Kanban 様式のボードに視覚化して、ToDo カードやイシュー、プルリクエストを次のカスタム列に進行させることができます。プロジェクトもリポジトリ単位または組織単位で作成できるため、複数のリポジトリのイシューやプルリクエストを 1 つの計画ページに取り込むことができます。

Salesforce ヘルプで Trailhead のフィードバックを共有してください。

Trailhead についての感想をお聞かせください。[Salesforce ヘルプ] サイトから新しいフィードバックフォームにいつでもアクセスできるようになりました。

詳細はこちら フィードバックの共有に進む