Gitのトラブルシューティング

Gitについてよくある質問をまとめています。

目次

認証

HTTPS接続（https://...）で「Authentication failed」エラーが発生する

「Authentication failed」エラーが発生する場合、BacklogのGit用パスワードが正しく設定されていない可能性が考えられます。状況に応じて以下のいずれかの対応をしてください。

パスワードを変更している場合

前回のGitを利用した後に、アカウントのパスワードを変更した場合は、変更後のパスワードをお試しください。もし引き続きエラーが発生する場合は、パスワードを変更した後に、改めてお試しください。

入力したパスワードの前後にタブキーや改行、制御文字などが入ってしまっている可能性もあります。メモ帳などのテキストのアプリケーションに貼り付けし、パスワードの文字の部分だけを選択した上で、コピーと貼り付けを行ってください。もしくは手入力などもお試しください。

2段階認証を設定している、または管理対象アカウントを利用している場合

2段階認証を設定している、または管理対象アカウントを利用している場合は、特別なパスワードを発行してください。発行したパスワードを利用してください。特別なパスワードの発行方法について、詳しくは特別なパスワードを参照してください。

上記いずれにも当てはまらない場合

認証情報に異なるものが入力されている、または過去の認証情報がキャッシュとして残っている可能性があります。以下いずれかの方法で、認証情報のクリア（リセット）をお試しください。

Windows（資格情報マネージャー）をご利用の場合

Windowsで認証情報をクリアする手順を説明します。

  1. 「コントロールパネル」＞「ユーザーアカウント」＞「資格情報マネージャー」>「Windows資格情報」をクリックします
  2. git:https://[スペースID].backlog.com のような項目を探し削除します

Mac（キーチェーンアクセス）をご利用の場合

Macで認証情報をクリアする手順を説明します。

  1. 「アプリケーション」＞「ユーティリティ」＞「キーチェーンアクセス」をクリックします
  2. 検索窓で「backlog」や「git」と入力します
  3. 該当するインターネットパスワードを削除します

Sourcetree をご利用の場合

OSの認証情報を削除しても、Sourcetreeのアプリケーション内に「認証アカウント」のリストとして古い情報が残っている場合にエラーが出続けることがあります。

エラーが出ている場合の手順を説明します。

  1. 「設定またはオプション」＞「認証」をクリックします
  2. アプリケーション内にある「認証アカウント」のリストからBacklogのアカウントを削除します
  3. 次回のプッシュ/プル時に表示されるダイアログで、新しいパスワードを入力します

Fork、TortoiseGit などのクライアントツールをご利用の場合

認証情報はOSに保存されています。ご利用の端末をご確認の上、Windows（資格情報マネージャー）をご利用の場合か、Mac（キーチェーンアクセス）をご利用の場合のいずれかの手順を実施ください。

VS Code、IntelliJ などのIDEをご利用の場合

認証情報はOSに保存されています。ご利用の端末をご確認の上、「Windows（資格情報マネージャー）をご利用の場合」か、「Mac（キーチェーンアクセス）をご利用の場合」のいずれかの手順を実施ください。

エラーが解消されない場合

問題の切り分けのため、以下の手順で「コマンドプロンプト（Windows）」または「ターミナル（Mac）」を用いたコマンドによる接続をお試しください。

確認の手順を説明します。

  1. コマンドプロンプト（またはターミナル）を起動します

  2. 以下のコマンドを入力して実行します

    git clone [リポジトリのURL]

    リポジトリURLは、プロジェクトのGit画面からコピーできます。

  3. パスワードを求められたら入力します

上記のコマンドで取得できた場合は、利用しているクライアントツールやアプリケーションの設定や、アプリケーション側の不具合の可能性が考えられます。クライアントツールやアプリケーションの設定等をご確認ください。

コマンドでも取得できない場合は、入力しているパスワードが間違っている可能性があります。利用しているパスワードやアカウントの状況をご確認ください。

それでも解決しない場合は、以下を添えてお問い合わせください。

  • 実施した操作とその結果(例：パスワードの変更をしたが、エラー内容が変わらない。資格情報マネージャーからの削除をしたが、認証できない）
  • gitのコマンドによる実行結果

HTTPS接続（https://...）で「Permission denied」エラーが発生する

「Permission denied」エラーが発生する場合、ユーザーの権限に問題がある可能性があります。

権限を確認する

「個人設定」>「ユーザー情報」＞「権限」で、「課題の閲覧のみ」の表示がないことをご確認ください。

Backlogの個人設定画面のスクリーンショット。権限に「課題の閲覧のみ」の制限が入っていることがわかる。

もし、「課題の閲覧のみ」と表示されている場合、管理者権限を持つユーザーに、ユーザーの「制限」設定を「制限なし」に変更するよう依頼してください。

権限の変更方法について詳しくは、ユーザーの追加-編集-削除>ユーザーを編集するを参照してください。

プロジェクトの参加状況を確認する

GitのHTTPSのURLに記載されているプロジェクトに参加しているかご確認ください。

参加しているプロジェクトの確認手順を説明します。

  1. GitのHTTPSのURLを確認します

    GitのHTTPSのURLは以下の構成にて作成されます。「.com」が「.jp」の場合もあります。
    https://[スペースID].backlog.com/git/[プロジェクトキー]/[リポジトリ名].git

  2. https://[スペースID].backlog.com/[プロジェクトキー]にアクセスできるか確認します

プロジェクトに参加していない場合は、「現在ログイン中のアカウントではこのスペースを表示できません」というエラーが表示されます。管理者、またはプロジェクト管理者にプロジェクトへの追加を依頼してください。

プロジェクトへの追加方法について詳しくは、ユーザー・チームをプロジェクトに追加する>ユーザーをプロジェクトに追加するを参照してください。

GitにアクセスしているIPアドレスを確認する

アクセス制限を利用しているスペースの場合、許可されていないグローバルIPアドレスからアクセスしている可能性があります。

アクセスしている端末のグローバルIPアドレスが許可されているか、管理者に確認してください。

プロキシーを利用している場合、アプリケーションごとに制限されていることがあります。その場合、例えばブラウザからBacklogを閲覧できても、コマンドプロンプト（またはターミナル）やクライアントツールは許可されておらず、Gitを利用できないことがあります。詳細は貴社のネットワーク担当者にご確認ください。

SSH接続で「Permission denied (publickey) 」エラーが発生する

公開鍵の登録漏れや鍵ペアの設定が誤っている可能性があります。

公開鍵の設定手順を説明します。

  1. SSH鍵ペアを生成します
  2. 「個人設定」 >「 SSH 公開鍵」をクリックします
  3. 公開鍵をBacklogに登録します

設定された公開鍵の前後にタブキーや改行、制御文字などが入っている可能性もあります。メモ帳などのテキストのアプリケーションに貼り付けし、公開鍵の文字の部分だけを選択した上で、コピーと貼り付けを行ってください。

管理対象アカウントに変更後、Gitの認証ができなくなった

NulabPassの管理対象アカウントは、Gitの認証に特別なパスワードが必要です。

特別なパスワードを発行し、発行したパスワードを利用してください。

特別なパスワードを発行する手順を説明します。

  1. 「個人設定」> 「パスワード」をクリックします
  2. 「新しいパスワードを発行」で使いたい機能を選択し、「登録」をクリックします

リポジトリ操作・パフォーマンス関連

Gitクローンでタイムアウトが発生する

Gitクローンでタイムアウトが発生する場合、以下いずれかが原因の可能性があります。

  • リポジトリのファイル数や容量が大きい
  • ネットワークに問題がある
  • 設定が誤っている

クライアントツールを利用している場合、クライアントツールのタイムアウトに関連する設定がないか確認してください。

もしくは、バッファサイズを調整することで回避できる可能性があります。

バッファサイズを調整する手順を説明します。こちらも併せてお試しください。

  1. 以下のコマンドで http.postBuffer の値を大きくします

    git config --global http.postBuffer 157286400

    数値は参考値です。参考値でも同じエラーが発生した場合は、現在の設定の2倍、それでも解決しない場合は4倍と、段階的に増やして再試行してください。

  2. 再度クローンします

バッファサイズを調整しても解決しない場合は、SSHによる接続をお試しください。SSHによる接続には、SSH公開鍵が必要です。SSH公開鍵の設定について詳しくは、Gitの概要>SSH公開鍵を参照してください。

プッシュ時に「error: RPC failed; HTTP 413」エラーが発生する

「error: RPC failed; HTTP 413」エラーは、巨大なバイナリファイルを追加した直後や、数千件のコミットを一気にプッシュしようとした際に発生することがあります。容量を超過している可能性があります。

バッファサイズを調整することで回避できる場合があります。

バッファサイズを調整する手順を説明します。

  1. 以下のコマンドで http.postBuffer の値を大きくします

    it config --global http.postBuffer 157286400

    数値は参考値です。参考値でも同じエラーが発生した場合は、現在の設定の2倍、それでも解決しない場合は4倍と、段階的に増やして再試行してください。

  2. 再度プッシュします

上記でも解決しない場合は、SSHによる接続をお試しください。SSHによる接続には、SSH公開鍵が必要です。SSH公開鍵の設定方法について詳しくは、Gitの概要>SSH公開鍵を参照してください。

「リポジトリの削除に失敗しました」エラーが発生する

リポジトリの容量が大きいことで、タイムアウトが発生している可能性があります。

調査のため、以下2点を添えてお問い合わせください。

  • プロジェクトキー
  • リポジトリ名

コミット履歴・表示

コミットしたユーザーとBacklog上のGitのコミット履歴にあるユーザー名が異なる

コミットしたユーザーのローカルにあるGitクライアントのuser.emailと、Backlogのメールアドレスが一致していない可能性があります。

以下のコマンドを実行し、Gitクライアントのメールアドレスと、Backlogに登録しているメールアドレスが同じかをご確認ください。

git config --global user.email

メールアドレスが異なる場合、いずれかのメールアドレスを変更し、GitクライアントのメールアドレスとBacklogに登録しているメールアドレスを一致させてください。

・既にコミット済みの履歴を変更することはできません
・Backlogに参加していないユーザーのコミットは、プッシュしたユーザーのコミットとして扱われます。そのため、プッシュしたユーザー名が表示されます

git filter-branchでコミットを削除したが、Backlog上に残っている

コミットを削除しても、Backlog上に情報が残っている場合、キャッシュとして残っている可能性があります。もしくは他のブランチ・タグ・プルリクエストなどに紐付いている可能性があります。

削除したコミットは、一定期間（約2週間程度）後に自動消去されます。 もし一定期間が経過した後も残っている場合は、他のブランチ・タグ・プルリクエストなどに紐付いている可能性があるため、それらの参照が残っているかご確認ください。

参照が残っていた場合は、該当のブランチ・タグ・プルリクエストを削除することで、削除した時点から、さらに一定期間が経過した後に削除されます。

ローカルではコミットされているが、Backlogの画面に表示されない、もしくは404エラーになる

コミットからBacklogに反映されるまで一定時間を要することがあります。反映前にアクセスしたか、一時的に反映できなかった可能性があります。数時間後に再度確認してください。

時間をおいても解決しない場合は、以下の2点を添えてお問い合わせください。

  • 該当のBacklog画面のURL
  • アクセスした日時

コミットメッセージと課題の紐付けが別プロジェクトに記録される

コミットしたプロジェクトのコミットコメントに、紐付け先のプロジェクトの課題キーを記載している可能性があります。同一スペース内のプロジェクトの場合、記載された課題キーが登録されているプロジェクトをもとに紐づけされます。

例： 

事象：プロジェクトA（PRJ_DEV）のリポジトリにコミットしたが、プロジェクトB（PRJ_PROD）の課題にコミットの履歴が記録された

原因：プロジェクトAのGitリポジトリのコミットコメントに、プロジェクトBの課題キーを記載したため発生した

別プロジェクトに課題の紐付けを行いたくない場合の手順を説明します。

  1. リポジトリが格納されているプロジェクトの「プロジェクト設定を開きます
  2. 「コミットと課題を連携する」のチェックを外して登録します

「コミットと課題を連携する」のチェックを外した場合、プロジェクトAにも紐付けされません。

Git機能・権限

Backlog上で一部のユーザーに対し、Git機能を閲覧のみにできますか

すべてのGit機能を制限することはできません。ただし、ブランチ保護ルールを利用することにより、「プッシュできるユーザーまたはチーム」を限定できます。

ブランチ保護について詳しくは、Gitのブランチ保護を設定するを参照してください。

ブランチ保護に対応していない機能は以下のとおりです。

  • リポジトリ追加
  • ブランチの削除
  • プルリクエストからのマージ

 Git機能を制限できますか

はい、できます。「プロジェクト設定」>「基本設定」にて「Gitを使用する」のチェックを外し「保存」してください。

ゲストユーザーがGitを利用できないのはなぜですか

ユーザーの権限が関係している可能性があります。

ユーザーの権限で「課題の登録のみ」または「課題の閲覧のみ」の制限がされている可能性があります。「課題の登録のみ」または「課題の閲覧のみ」の制限がされている場合、Gitを利用できません。「制限なし」に変更する必要があります。ユーザーの権限を変更する方法について、詳しくはユーザーの追加・編集・削除 > ユーザーを編集するを参照してください。

プルリクエストの承認者を限定できますか

いいえ、できません。

運用ルール等でカバーすることをご検討ください。

外部ツール連携

GitHubやBitBucketと直接連携できますか

いいえ、できません。GitHubやBitBucketと直接連携する方法は現在提供していません。

直接連携する機能はありませんが、BacklogにはWebhookやAPIがあります。連携先とBacklog、双方のWebhookやAPIを介して外部サービスと連携できます。利用している環境や使用用途に合わせてご検討ください。

 

連携するためにはLambdaやZapierなどの中継システムが必要です。
中継システムの構築方法は、サポートの対象外です。

パーソナルアクセストークンの発行はできますか

いいえ、できません。

Backlogにはパーソナルアクセストークンに該当するものはありません。

パーソナルアクセストークンに代わるものとして、特別なパスワードをGit接続専用パスワードとして発行できます。特別なパスワードはパーソナルアクセストークンとしての正式なサポート機能ではありませんが、HTTPS接続時の認証手段としてご検討ください。なお、特別なパスワードの利用には2段階認証の設定が必要です。詳しくは特別なパスワードを参照してください。

移行・統合

別スペースのGitリポジトリを移行できますか

はい、できます。Gitリポジトリは分散型バージョン管理システムのため、Gitリポジトリをそのまま移行先にプッシュすることで、これまでの履歴も合わせて移行できます。

Gitリポジトリを移行する手順を説明します。

1.移行元のリポジトリの取得方法

リポジトリの移行には、ブランチも含め全てローカルへ取得する作業が必要です。

そのため、まずは移行元のリポジトリを取得してください。 OS（Windows/Mac等）やツールによって具体的な操作手順が異なります。利用環境に合わせた方法で取得・移行を進めてください。

Backlogでは、コミット履歴の正確な反映とデータの整合性を担保するため、mirrorオプションによる操作は非推奨です。 そのため、移行の際は各ブランチを個別に取得・プッシュしてください。

Mac / Linux / WSL (bash) の場合

以下のコマンドでリポジトリを取得してください。

for branch in `git branch -r | grep -v '->'`; do
    git branch --track ${branch#origin/} $branch
done
git fetch --all
git pull --all

Windows PowerShell の場合

以下のコマンドでリポジトリを取得してください。

git branch -r | ForEach-Object {
    $branch = $_.Trim()
    if ($branch -notmatch '->' -and $branch -like 'origin/*') {
        $localBranch = $branch -replace 'origin/', ''
        git branch --track $localBranch $branch
    }
}
git fetch --all
git pull --all

上記以外の場合、ブランチを手動で一つずつチェックアウトしてください。リポジトリを取得する手順を説明します。

  1. git branch -r を実行して、出てきたリストをメモ帳などにコピーします
  2. origin/ 以外の名前（ブランチ名）を抜き出します
  3. 1つずつ git checkout [ブランチ名] を実行します

2. 移行先へのプッシュ

取得したリポジトリを移行先にプッシュすることで移行を完了してください。リポジトリを移行先にプッシュする手順を説明します。

  1. 移行先のBacklogの「プロジェクト設定」 >「基本設定」で、「Gitを使用する」にチェックを入れ「保存」します
  2. Git でリポジトリを作成します
  3. 作成したリポジトリに以下のコマンドでプッシュします
git push [新リポジトリのURL] +[デフォルトブランチ名]
git push --all [新リポジトリのURL]
git push --tags

容量

Gitの利用を無効にしても使用容量が減りません。なぜですか

データが正しく削除されていない可能性があります。

以下の操作を実行し、事象が改善するか確認してください。

既に操作している場合でも再実行してください。

  1. 「プロジェクト設定」>「基本設定」で「Gitを使用する」にチェックをし「保存」をクリックします
  2. 「プロジェクト設定」>「Git」>「設定」をクリックします
  3. 「Gitの利用を停止する」>「リポジトリを削除する」をクリックして、リポジトリを全て削除します

引き続き事象が改善しない場合、プロジェクトキーを添えてお問い合わせください。

リポジトリを削除してもGitやGit LFSの使用容量が残っているのはなぜですか

データが正しく削除されていない可能性があります。調査のため、以下の2点を添えてお問い合わせください。

  • 該当のプロジェクトキー
  • リポジトリ名

使用容量（リモート）とローカルのリポジトリのサイズが違うのはなぜですか

リポジトリのサイズがリモートとローカルで異なるのは、Gitの正常な仕様です。そのため使用容量のサイズと、ローカルのリポジトリのサイズが完全に一致することはありません。

一致しない理由としては、主に以下の4点が挙げられます。

  • 管理用データの有無
  • 取得している範囲の違い
  • 最適化（圧縮）の状態
  • ファイルシステムによる違い

管理用データの有無

サーバー側には、サービス上での表示や検索を高速化するための「インデックス」や「一時ファイル」が含まれています。これらはサーバー専用のデータであるため、ローカルにはダウンロードされません。その分の差異が発生することでサイズが一致しません。

取得している範囲の違い

ローカルでは、現在作業しているブランチのデータのみが展開されています。一方、サーバー側には「過去のすべての履歴」や「すべてのブランチ」のデータが完全に保管されています。そのため、その分サイズが大きくなる傾向があります。

最適化（圧縮）の状態

Gitのデータは自動で圧縮されますが、そのタイミングはサーバーとローカルで異なります。どちらがより整理されているかによって、サイズに差が生じます。

ファイルシステムによる違い

利用環境により、ストレージの「最小単位（ブロックサイズ）」が異なります。例えばLinux系やMac、WindowsなどOSによってブロックサイズが異なります。そのため、データが同じであっても、OSが計算するディスク上のサイズは必ず差異が生じます。

「507 Insufficient Storage」のエラーが出るのはなぜですか

「507 Insufficient Storage」エラーが発生する場合、Backlogの容量上限に達しています。エラーを解消するためには以下いずれかの方法を検討してください。

Gitリポジトリのサイズに上限はありますか？

はい、あります。リポジトリサイズは、1リポジトリにつき最大10GBまでです。

Gitリポジトリのサイズが上限に達した場合、どうしたらいいですか。

リポジトリのサイズが10GBを越えた場合、エラーメッセージが返却され、プッシュがブロックされます。以下の手順で、現在の最新の情報のみをコピーした新規リポジトリを作成してください。

  1. 移行前のリポジトリのURLを格納します
  2. --depth 1を指定して移行前のリポジトリの最新のコミットを取得します
  3. cloneしたリポジトリを移動します
  4. 移行前のリポジトリの最新のコミットIDを格納します
  5. .git以下をすべて削除します
  6. gitリポジトリとして初期化します
  7. すべてのファイルをインデックスに追加します
  8. 移行前のリポジトリのURLと、先頭のコミットIDをコミットメッセージに含めてコミットします
  9. 移行後のリモートリポジトリのURLを追加します
  10. 移行後のリモートリポジトリへプッシュします

画像ファイルやバイナリファイルなどを管理する場合は、 Git LFSの利用を検討してください。Git LFSを利用することで、大容量のファイルをBacklogのGitで管理できます。Git LFSについて詳しくはGit LFSの使用方法を参照してください。

リポジトリのサイズが大きくcloneできない場合、shallow cloneの利用をお試しください。

git clone --depth 1 [リポジトリのURL]
git fetch --unshallow

Gitリポジトリサイズの上限に達した場合のエラーメッセージ

サイズごとのエラーメッセージは以下のとおりです。

1GB

This repository have exceeded 1.0G in size. If it exceeds 10.0G it will be put into read-only mode.

5GB

This repository have exceeded 5.0G in size. If it exceeds 10.0G it will be put into read-only mode.
Please reduce your repository size.

10GB

The push was rejected because repository would have exceed the 10.0G limit.
Please reduce the size of the files included in the commits and push again.

リポジトリサイズが10GB未満の場合、メッセージが表示されていても通常どおりGitを使用できます。

リポジトリサイズの確認方法を教えてください

ローカルリポジトリの.gitディレクトリのサイズを確認してください。

サイズを確認する手順を説明します。

  1. 対象のリポジトリをcloneします

    git clone [リポジトリのURL]

  2. 取得したリポジトリのディレクトリに移動します

    cd 取得したリポジトリのディレクトリ

  3. .gitディレクトリのサイズを確認します

    du -sh .git

使用容量とローカルのリポジトリのサイズが異なることがあります。詳しくは使用容量（リモート）とローカルのリポジトリのサイズが違うのはなぜですかを参照してください。

この記事は役に立ちましたか？

関連記事