SlackとMicrosoft TeamsでGitHubを使う開発チームは、1つの会話で複数のコードリポジトリを扱えるようになった。イシュー作成からコード修正、バグ調査まで、リポジトリごとに新たな会話を開かずに続けられるという変化だ。
1. リポジトリが違っても会話は続く
GitHubは2026年10月15日の変更ログで、複数リポジトリへの対応を発表した。リポジトリは、プロジェクトのコードと変更履歴をまとめておく場所だ。今回の改善で、異なる場所にある作業を1つの会話から依頼できるようになった。
例えば、画面を担当するコードとサーバーを担当するコードが別のリポジトリにあっても、両方を調べるバグ調査を依頼できる。会話の単位が1つのリポジトリに縛られない点が重要であり、複数のリポジトリを1つに統合するという意味ではない。
2. イシュー作成からプルリクエストの確認まで
原文は4つの活用例を挙げている。1つ目は、会話で挙がったバグを追跡するために特定のリポジトリにイシューを作り、その会話の文脈を活用させる依頼だ。議論の内容を作業項目に移す事例である。
2つ目は、画面側のリポジトリのバグを修正し、プルリクエストを開かせることだ。プルリクエストは、修正したコードをプロジェクトに反映する前にレビューできるように提出する提案を指す。ここではコード修正とレビュー依頼の作成を1つの依頼でつなぐ。
3つ目は、複数のリポジトリで自分が開いているプルリクエストをまとめて確認し、注意が必要な項目を挙げさせることだ。4つ目は、画面側とサーバー側のリポジトリのコードを併用してイシューを調査させる依頼である。それぞれ、分散した作業の確認や、リポジトリをまたぐ問題の調査の例だ。
3. 呼び出し位置とSlackの文脈活用も変わる
メッセージでGitHubを呼び出す位置も自由になった。メッセージの先頭だけでなく、どの位置でも@GitHubにメンションできるようになった。原文では、会話中にリポジトリをより簡単に切り替えられるよう改善したとも説明している。
Slackでは、共有されたメッセージや会話のまとまりであるスレッドを、作業の文脈として利用できる。以前の議論を説明し直すために、詳細をコピーして貼り付ける手間を減らす変化だ。ただし、同じ文脈活用機能がTeamsにも提供されるかは示されていない。
4. 作業開始と中断後の復旧を改善
GitHubは、両メッセンジャーでエラーを減らし、作業開始を改善するとともに、中断後もより円滑に作業を復旧できるよう手を加えたと説明した。これは、複数リポジトリ対応とともに発表された信頼性の改善である。
この説明を、作業が中断なく完了するという保証と受け取るべきではない。エラーの減少幅や作業開始までの時間、復旧成功率といった数値は示されていない。改善の方向は分かるものの、速度や安定性の向上の程度を数値で比較する根拠はない。
5. 切り替えの負担とレビュー範囲を併せて考える
利点は、リポジトリごとに会話を移す負担が減ることだ。特に複数のリポジトリのコードを併せて調べる必要がある調査では、関連する依頼を1つの流れにまとめられる。Slackの会話の文脈活用は、これに加えて以前の議論を伝え直す手間も減らす役割を果たす。
一方で、複数のリポジトリを一度に扱う利便性と、結果をレビューする範囲は分けて考える必要がある。チームは会話の切り替えが減る利点だけでなく、依頼対象や結果がどのリポジトリに該当するかを確認する負担も併せて検討するとよい。
1つの会話で扱えるリポジトリ数の上限、リポジトリを切り替える具体的な操作方法、料金プランや課金範囲は原文に示されていない。導入を検討するなら、実際の利用条件を別途確認すべき項目である。
今回の改善の要点は、複数リポジトリの作業を1つの会話につなぐことにあり、導入の判断では切り替えの利便性と作業範囲を確認する負担を併せて基準にすべきだ。