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

学習の目的

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

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

GitHub ロゴ

GitHub リポジトリのツアー

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

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

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

Git リポジトリの作成

GitHub 組織の設定

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

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

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

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

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

リポジトリのコード

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

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

GitHub リポジトリのブランチの切り替えを示すスクリーンショット。

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

イシューは、フォーラムのようなスレッド化されたディスカッションで、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 つの計画ページに取り込むことができます。