2. よくあるトラブルとその対処法を整理
GitHub導入初期には、いくつか典型的なトラブルも発生しがちです。その対処法を事前に知っておくことで、慌てずに対応できます。ここでは特によく発生する4つのトラブル事例とその解決方法をご紹介します。
トラブル1: 誤って公開リポジトリに機密情報をコミットしてしまった
対処方法：万一社外秘情報をPublicリポジトリに上げてしまった場合、すぐにリポジトリをPrivateに切り替えてください。
情報が広まっていないか確認し、場合によってはGitHubサポートにキャッシュ削除を依頼します。またそのコミット履歴を削除（履歴を書き換え）する必要があります。
Gitコマンドでの対処（filter-repoなど）はIT部門の技術者に任せましょう。
重要なのは社内教育で、秘密情報（顧客名簿や認証キー等）は決してGitHubに上げないルールを徹底することです。
導入前に想定される機密を洗い出し、「これはGitHubに載せない」「載せる場合は暗号化する」等のガイドラインを策定しておくと安心です。
トラブル2: メール通知やSlack通知が多すぎて鬱陶しい
対処方法：GitHubの通知はIssueへのコメントやPRへのメンションなど頻繁に飛ぶため、慣れないと「通知疲れ」する人もいます。
各自の通知設定をチューニングすることが大切です。不要な通知は無視するかフィルタリングし、Watchingするリポジトリも必要なものだけにします。
Slack連携も、重要なものだけチャンネルに流すようWebhookを調整可能です。また「通知が多い＝それだけ活動が活発」という裏返しでもあるので、情報を追うコツを新人にレクチャーすることも有効です。例えば朝にメール通知をざっとチェックし、関係あるものだけGitHub上で詳細を見る、という運用であれば負担は減ります。
慣れてくれば、逆に通知が来ないと不安に感じるくらいになります。
トラブル3: 予期せぬコンフリクトや操作ミスで作業が止まった
対処方法：GitHub上での操作ミス（例えば誤って大事なファイルを削除してコミット）や、複雑なコンフリクトが起きてマージできないケースもあります。
困ったときは無理に進めず助けを求めることが大事です。
IT担当者やGitに詳しいエンジニアに相談すれば、ログを見て適切なリカバリ策を提案してくれるでしょう。
最悪、バックアップからファイルを戻すこともできます。GitHubは基本的に変更履歴を持っているため、「消えたと思ったら実は履歴に残っていた」ということも多いです。
慌てず履歴を探すか、詳しい人に協力してもらいましょう。これも経験を積めば自己解決できるようになります。
トラブル4: GitHubが一時的に利用不能になった場合の業務影響
対処方法：クラウドサービスである以上、GitHub本体がメンテナンスや障害でダウンする可能性もゼロではありません。
万一に備え、重要ファイルのローカルコピーやエクスポートを定期的に取っておくと安心です。
幸いGitHubは信頼性が高く、長時間使えない事態は稀です。またオフラインで作業できるGitの利点もあります（ただし本サイトではコマンド利用範囲外）。
どうしても不安なら、自社サーバ版のGitHub Enterpriseを検討する方法もありますが、コストとの見合いです。一般には、メールサーバが止まった場合と同等のBCPを想定すればよいでしょう。
つまり、最悪半日〜1日使えなくても致命傷にならないよう業務フローを工夫する、といったことです。例えば前日資料をローカルにも保存しておくなど簡単な対策で十分です。
トラブル対策のポイント
これらQ&Aやトラブル事例は、導入プロジェクト時に社内FAQとしてまとめて展開するとよいでしょう。人は未知のものに不安を感じますが、具体的な疑問に答えを用意することで安心して使い始めることができます。本章の内容を参考に、自社の状況に合わせたFAQ集を作成してみてください。
演習課題
考えてみよう
以下の2つの課題に取り組んでみましょう：
- あなたのチームメンバーから出そうなGitHubに関する質問を3つ想定し、それに対する回答を考えてみましょう（前節のQ&Aにないもの）。例えば「紙の文書はどうするの？」等、自分たちの業務特性に合わせた疑問を想像します。それに対し、本サイトで学んだ知識を踏まえて回答を書いてみてください。
- 過去の自社プロジェクトで起きた情報共有上のトラブルを一つ思い出し、それがもしGitHubを使っていたら防げたか、あるいはどう対処できたかを検討してみてください。それをチームで共有し、GitHub導入のメリット/デメリットの理解を深めましょう。
まとめ
GitHubの導入には様々な疑問やトラブルが付きものですが、それらに事前に備え、適切な対応策を講じることで、円滑な導入を実現できます。重要なのは「完璧を目指す」のではなく、「トラブルが起きても適切に対応できる」環境を作ることです。そして、小さく始めて徐々に広げていく段階的アプローチが、多くの組織で成功しています。