【実務・中級編】GitHubで「Permission Denied」が発生!原因別のトラブルシューティング集 – バージョン管理・CI/CD活用バイブル

GitHub「Permission Denied」の迷宮を脱出せよ:テックリードが伝授するCI/CDの足元を固める極意

エンジニア諸君。開発のスピードを鈍らせる最大の敵は、複雑なバグではない。「Permission Denied」といった、環境設定の不備による無駄な足止めだ。

GitHubとの接続エラーで30分溶かしているようでは、一流のDevOpsエンジニアとは言えない。今日は、この泥沼から最短で抜け出し、さらにチームの生産性を加速させるための「プロの技術」を共有する。

—

1. 「Permission Denied (publickey)」を即座に葬るチェックリスト

SSH接続エラーの9割は、以下のいずれかに集約される。迷わず叩け。

① 秘密鍵がSSHエージェントに登録されているか?

鍵を作っただけでは意味がない。エージェントにロードされているか確認せよ。

現在ロードされている鍵を確認
ssh-add -l

なければ追加(~/.ssh/id_ed25519を想定)
ssh-add ~/.ssh/id_ed25519

② configファイルでホストを明示しているか?

複数のGitHubアカウント(個人と業務など)を使い分ける場合、`~/.ssh/config` の設定は必須だ。

~/.ssh/config
Host github.com-work
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_work

これで `git clone git@github.com-work:Org/Repo.git` と指定すれば、鍵の迷子を防げる。

③ 権限設定(パーミッション)の罠

SSHは、鍵ファイルの権限が緩すぎるとセキュリティリスクとみなして接続を拒否する。

chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

—

2. 開発体験(DX)を爆速にする「神」テクニック

トラブルシューティングで時間を浪費するな。日常の操作を自動化し、脳のメモリをコードの設計に全振りしろ。

A. 絶対に入れるべき「GitHub CLI (gh)」

ブラウザを開くのは敗北だ。ターミナルで全てを完結させろ。

  • `gh pr create`: PR作成をCLIで完結。
  • `gh run watch`: CIの失敗をリアルタイムで追跡。
  • `gh repo fork –clone`: フォークからクローンまで一撃。

B. 隠れたキーボードショートカット

GitHubのリポジトリ画面で `t` を押せ。ファイル検索モードになる。マウスでディレクトリを掘るのは今日で終わりにしろ。

—

3. チームの生産性を最大化する「設定共有」ルール

「個人の環境」を「チームの資産」に昇華させるのがテックリードの役割だ。

`.editorconfig` と `.github/` の徹底

プロジェクトのルートに以下のディレクトリを配置し、コミットせよ。

  • .editorconfig: インデントや改行コードをチームで統一。これがないプロジェクトはカオスへの第一歩だ。
  • .github/workflows/: CI/CDのパイプラインをコード化する。
  • .github/CODEOWNERS: 特定のディレクトリの変更には必ず特定のレビュアーを割り当てる。

実用的な YAML ベストプラクティス (CI/CD例)

GitHub Actionsの再利用可能なワークフローを活用せよ。

.github/workflows/ci.yml
name: CI Pipeline
on: [push, pull_request]

jobs:
test:
runs-on: ubuntu-latest
steps:

  • uses: actions/checkout@v4
  • name: Setup Node

uses: actions/setup-node@v4
with:
node-version: ’20’
cache: ‘npm’ # キャッシュ設定でビルド時間を劇的に短縮

  • run: npm install
  • run: npm test

—

4. プロの視点:マージ戦略の極意

「なんでもマージしていい」はチームを殺す。以下を鉄則とせよ。

1. Squash Mergeを基本に: `main` ブランチには意味のある単位でコミットをまとめろ。`fix typo` が10個並んでいる履歴は技術的負債だ。
2. Protection Rules: `main` ブランチに対しては必ず「プルリクエストを必須」にし、「CIがパスすること」を条件にする。人間が確認する前に、ツールに弾かせろ。
3. Draft PRの活用: 作業途中のコードでも、設計の相談があるならDraft PRとして公開せよ。早すぎるフィードバックこそが修正コストを下げる。

—

最後に

DevOpsとはツールを使いこなすことではない。「摩擦を排除し、価値あるコードを書く時間を最大化すること」だ。

Permission Deniedが出た時、それをただのエラーと捉えるか、環境自動化へのチャンスと捉えるか。その視点の差が、君を一段上のエンジニアへと押し上げる。

さあ、ターミナルを閉じずに、次なるデプロイへ向かえ。コードは待ってくれない。

タイトルとURLをコピーしました