Skip to main content

このバージョンの GitHub Enterprise はこの日付をもって終了となります: 2022-10-12. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise にアップグレードします。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください

GitHub でのコミュニケーション

GitHub Enterprise Server 上でさまざまな種類のディスカッションを用い、特定のプロジェクトや変更について、そしてもっと幅広くアイデアや Team のゴールについて話し合うことができます。

はじめに

GitHub Enterprise Server には、コミュニティと密接にやり取りできる、コラボレーション可能なコミュニケーション ツールが組み込まれています。 このクイックスタート ガイドでは、ニーズに適したツールの選択方法について説明します。

行いたい会話の種類に応じて、issue、pull request、チーム ディスカッションを作成して参加できます。

GitHub Issues

  • バグ報告や改善計画、フィードバックなど、プロジェクトの特定の詳細についてのディスカッションに役立ちます。
  • リポジトリに固有であり、通常は明確なオーナーがいます。
  • 多くの場合、GitHub のバグ追跡システムと呼ばれます。

Pull Request

  • 特定の変更を提案できます。
  • 他のユーザーが提案した変更について直接コメントできます。
  • リポジトリに固有です。

Team ディスカッション

  • プロジェクトをまたぎ、特定の issue または pull request に属していない会話に対して、チームのページで開始できます。 アイデアについてディスカッションするためにリポジトリでIssueを開く代わりに、Teamディスカッションで会話することでTeam全体を巻き込めます。
  • 計画、分析、設計、ユーザー調査、一般的なプロジェクトの意思決定に関するチームのディスカッションを 1 か所で行うことができます。
  • コードベースの外部でコラボレーション エクスペリエンスを提供し、アイデアのブレーンストーミングを可能にします。
  • 多くの場合、明確なオーナーはいません。
  • 多くの場合、操作可能なタスクは発生しません。

どのディスカッション ツールを使用すべきか

issue のシナリオ

  • タスク、機能強化、バグを追跡したい。
  • バグ報告を提出したい。
  • 特定の機能に関するフィードバックを共有したい。
  • リポジトリ内のファイルについて質問したい。

問題の例

この例では、GitHub ユーザーがどのようにしてドキュメント オープン ソース リポジトリに issue を作成してバグを認識させ、修正プログラムについて話し合うかを示しています。

issue の例

  • あるユーザーが、中国語版の GitHub Docs のページ上部にあるバナーの青い色で、バナー内のテキストが読めなくなることに気付きました。
  • そのユーザーはリポジトリに issue を作成し、問題について述べ、修正プログラム (バナーに別の背景色を使用する) を提案しました。
  • ディスカッションが続き、最終的には、修正プログラムの適用に関する合意に達します。
  • これで、共同作成者が修正プログラムを含む pull request を作成できます。

pull request のシナリオ

  • リポジトリの入力ミスを修正したい。
  • リポジトリに変更を加えたい。
  • 変更を加えて issue を修正したい。
  • 他の人によって提案された変更についてコメントしたい。

プル要求の例

この例では、GitHub ユーザーがどのようにしてドキュメント オープン ソース リポジトリに pull request を作成して入力ミスを修正するかを示します。

pull request の [会話] タブで、作成者が pull request を作成した理由を説明します。

pull request の例 - [会話] タブ

pull request の [ファイルの変更] タブには、実装された修正プログラムが表示されます。

pull request の例 - [ファイルの変更] タブ

  • この共同作成者は、リポジトリの入力ミスに気付きました。
  • このユーザーが、修正プログラムを含む pull request を作成します。
  • リポジトリの保守担当者は、pull request を確認し、それにコメントを付けてマージします。

チーム ディスカッションのシナリオ

  • リポジトリ内の特定のファイルに必ずしも関連していない質問がある。
  • コラボレーターやチームとニュースを共有したい。
  • 自由回答の会話を開始または参加したい。
  • チームで発表を行いたい。

チーム ディスカッションの例

この例は、octo-team チームのチーム投稿を示しています。

チーム ディスカッションの例

octocat のチーム メンバーはチーム ディスカッションを投稿し、さまざまなことをチームに通知しました。

  • Mona というチーム メンバーがリモート ゲーム イベントを開始しました。
  • チームが GitHub Actions を使用してどのようにドキュメントを生成するのかを説明するブログ記事があります。
  • April All Hands に関する資料を、すべてのチーム メンバーが閲覧できるようになりました。

次の手順

これらの例では、GitHub Enterprise Server で会話に最適なツールを決定する方法を示しました。 しかし、これは始まりにすぎません。これらのツールをニーズに合わせて調整するためにできることは、他にもたくさんあります。

たとえば、issue の場合は、より迅速に検索できるように issue にラベルをタグ付けしたり、共同作成者が有意義な issue をオープンできるように issue テンプレートを作成したりできます。 詳細については、「Issue について」と「Issue と pull request のテンプレートについて」を参照してください。

pull request の場合、提案された変更がまだ進行中の場合は、下書きの pull request を作成できます。 下書きの pull request は、レビュー準備完了としてマークされるまでマージできません。 詳細については、「pull request について」を参照してください。

チーム ディスカッションの場合は、チームのページでディスカッションを編集または削除したり、チーム ディスカッションの通知を構成したりできます。 詳細については、「チーム ディスカッションについて」を参照してください。