Git についてよく寄せられる質問

まず、 origin リポジトリが構成されていることを確認します。 git cloneを使用してリポジトリを複製した場合は、既に作成済みです。 ローカルに存在しないブランチをチェックアウトすると、Git は同じ名前のリモート ブランチが存在するかどうかを判断します。 その場合、Git はリモート ブランチを参照するローカル ブランチを作成します。 git pull を使用してコミットをダウンロードすると、ローカルでブランチの履歴が更新されます。

引数なしで git branch を実行してローカルブランチを表示し、チェックアウトしたブランチを強調表示します。Visual Studio では、ローカル Git リポジトリに格納されているプロジェクトを操作すると、ステータス バーに現在のブランチが表示されます。

論理的に異なる変更を行うには、個別のコミットを行います。 コミットをログブックのエントリと考えてください。 注目すべき変更を加えたら、必ずコミットに記録してください。 一般的なアプローチは、ローカルコミットを頻繁に許可し、プッシュする前にリベースを通してそれらをスカッシュすることです。 この方法では、コミット履歴を合理化したまま、柔軟性が提供されます。

コミットと共同作成者が多い大規模なプロジェクトでは、 main ブランチ履歴には、プロジェクト全体の進行状況よりもトピック ブランチの開発を反映できます。 コミットをスカッシュとリベースを実行することで、ブランチ上のコミットを圧縮できます。 コミットをスカッシュすると、ブランチ履歴が簡略化され、マージ後にクリーンなメイン ブランチが生成されます。

git blame コマンドを使用して、ファイルに対して特定の変更を行ったユーザーを確認します。 ローカル リポジトリから、git blame パラメーターを指定して-Lを実行し、目的の行を指定します。 Blame は、最後に各行を更新したコミットとその変更の作成者を示す書式設定された出力を生成します。

> git blame Example_repo -L 20,+40  # show the blame output for the next 40 lines starting at line 20

215d1108 (Example User 2015-11-21 09:54:23 -0800 20) line 20 of the code
215d1108 (Example User 2015-11-21 09:54:23 -0800 21) line 21 of the code
215d1108 (Example User 2015-11-21 09:54:23 -0800 22) line 22 of the code

Blame はコミット履歴を検索します。 また、Web ポータルでファイルの履歴を確認して、いつ誰が変更を行ったかを判別することもできます。 リポジトリとブランチの コード エクスプローラー を開き、調べるファイルを選択します。 Azure Repos は、現在のブランチ上のそのファイルの完全なコミット履歴を表示します。

Git で別のブランチをチェックアウトすると、ファイル システム上のファイルの状態に影響します。 Git ではコミット履歴を使用して、作業ディレクトリが選択したブランチと一致することを確認します。 コミットされていない変更がある間にブランチを変更しようとすると、チェックアウト中にそれらの変更が上書きされます。 偶発的なデータ損失を防ぐために、Git はチェックアウトをブロックします。 次のようなオプションがあります。

• 変更を破棄し、最新のコミットに戻ります。 最新のコミットにロールバックする手順については、 Git での変更の取り消 しを参照してください。
• 変更をコミットします。 コミットを使用した Git での作業の保存に関する記事を参照してください。
• 現在の作業を一時保存して後で変更を保存し、ワークスペースを最後のコミットにリセットします。

この問題は、大きなバイナリ ファイルでのマージの競合が原因で発生します。 現在のファイル サイズの制限は 100 MB です。 この問題を回避するには、ターゲットをソースにローカルにマージし、競合を解決して、変更をプッシュします。

大きなバイナリ ファイルに Git LFS (Large File Storage) を使用して競合を回避し、リポジトリ全体のサイズを管理します。これは、複製とプッシュ時間に影響します。

変更をコミットせずに保存するには、Git stashを使用します。 このコマンドは、現在のステージングされた変更とステージングされていない変更をブランチに保存し、ブランチを最後のコミットの状態に戻します。 その後、別のブランチに切り替えて作業を完了し、後で stash apply 実行して変更を復元できます。

git stash
Saved working directory and index state WIP on feature1: be26067 updated endpoint docs
HEAD is now at be26067

git stash applyを実行すると、最も最近スタッシュされた変更が現在のブランチに適用されます。 ファイルが競合している場合は、 stash は非コンフリクト ファイルを復元し、残りのファイルに競合マーカーを作成します。 競合を手動で解決します。

スタッシュが不要になったら、 git stash dropで削除します。 このコマンドは、最新のスタッシュを削除します。

複数のスタッシュを持つことができますが、それぞれを明示的に適用して削除する必要があります。 詳細については、 Git Stash のドキュメントを参照してください。

既定では、Git はコミット メッセージのプロンプトを表示し、リベースを実行し、入力を必要とする他のタスクを処理するときに、コマンドライン エディターを使用します。 git configを使用して既定のエディターを構成します。

> git config core.editor _path_to_editor_ _options_to_editor_

Git for Windows を使用すると、メモ帳をエディターとして簡単に設定できます。

> git config core.editor notepad

このコマンドは、Git テキスト編集を処理するように Windows メモ帳を構成します。 コミット メッセージの優先列幅を指定することもできます。

> git config format.commitMessageColumns 72 

この設定は、優先される 72 文字の列幅でコミット メッセージ テキストをラップします。

Git にはコミットごとにユーザー名と電子メール アドレスが含まれており、Azure Repos はコミットとプル要求を表示するときにこの情報を使用します。 コマンド ラインで名前と電子メールを更新するには、 git config コマンドを使用します。

> git config --global user.email "example-user@example-site.com"
> git config --global user.name "Example User"

--global オプションは、このシステム上のすべての Git リポジトリのコミットに含まれるメール アドレスと名前を設定します。 1 つのリポジトリの設定を変更するには、リポジトリ ディレクトリに移動し、 --global フラグなしで上記のコマンドを実行します。

Visual Studio から名前と電子メールの設定を変更することもできます。 Git メニューの [設定] を選択します。 [オプション] ダイアログで、Git グローバル設定または Git リポジトリ設定>General を選択します。

詳細トレースを有効にして、詳細なエラー情報を取得します。 Git コマンドを実行する前に、次の環境変数を設定します。

set GIT_TRACE=1
set GIT_TRACE_PACKET=1
set GIT_CURL_VERBOSE=1

トレース出力は、障害がネットワーク接続、プロキシ構成、SSL 証明書、または認証のいずれに関連しているかを判断するのに役立ちます。 Git 環境変数の詳細については、「 Git Internals - 環境変数」を参照してください。

プロキシ サーバーの背後にあり、Git がプロキシ サーバーを使用するように構成されていない場合、複製とプッシュ操作は、 407、 502、または "アクセスできない" エラーで失敗します。

git config --listを実行して、プロキシが既に構成されているかどうかを確認します。 そうでない場合は、プロキシをグローバルに設定します。

> git config --global http.proxy http://proxyUsername:proxyPassword@proxy.server.com:port

特定の URL に対してのみプロキシを構成するには:

> git config --global http.https://dev.azure.com.proxy http://proxyUsername:proxyPassword@proxy.server.com:port

詳細については、 Git 構成のドキュメントを参照してください。

パスワードの変更またはキャッシュされた資格情報が古い場合、Git の複製またはプッシュ操作は認証エラーで失敗します。 Git Credential Manager (GCM) をリセットして問題を解決します。

> git config --global --unset credential.helper
> git config --global credential.helper manager

Windows 資格情報マネージャーでキャッシュされた資格情報を直接削除することもできます。

1. コントロール パネル>User Accounts>Credential Manager を開きます。
2. [Windows 資格情報] を選択します。
3. git:https://dev.azure.com/<orgname>のエントリを検索して削除します。

または、コマンド ラインを使用します。

> cmdkey /list | findstr "git"
> cmdkey /delete:git:https://dev.azure.com/<orgname>

macOS では、 git credential reject を実行して、保存されている資格情報をクリアします。

echo url=https://dev.azure.com/<orgname> | git credential reject

資格情報をクリアした後、複製またはプッシュ操作を再試行します。 Git では、再認証を求められます。

自己署名証明書または内部 CA 証明書を使用する Azure DevOps Server インスタンスを複製またはプッシュすると、Git は次のエラーで失敗します。

fatal: unable to access '...': SSL certificate problem: unable to get local issuer certificate

オプション 1: Windows SChannel を使用する (Windows で推奨)

バンドルされた OpenSSL CA バンドルの代わりに Windows 証明書ストアを使用するように Git を構成します。 Windows がサーバーの証明書または CA を信頼している場合、それ以上の手順は必要ありません。

> git config --global http.sslBackend schannel

Visual Studio での SSL バックエンドの構成の詳細については、「 Git 設定 - 暗号化ネットワーク プロバイダー」を参照してください。

オプション 2: Git を CA 証明書にポイントする

ルートまたは中間 CA 証明書を Base-64 でエンコードされた .crt ファイルとしてエクスポートし、その場所を Git に指示します。

> git config --global http.sslCAInfo C:/Users/<yourname>/my-ca-cert.crt

また、バンドル全体をオーバーライドするのではなく、Git の既存の CA バンドル (通常は C:\Program Files\Git\mingw64\etc\ssl\certs\ca-bundle.crt) に証明書を追加することもできます。

自己署名証明書を使用するパイプライン エージェントのシナリオについては、 プロキシの背後または自己署名証明書を使用したセルフホステッド エージェントの実行に関するページを参照してください。

関連するコンテンツ

• Azure Repos Git のドキュメント
• 既存の Git リポジトリを複製する
• コミットを使用して作業を保存する
• Git ブランチを使用する