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

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

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

論理的に異なる変更には、個別のコミットを作成することをお勧めします。 コミットをログブックのエントリと考えてください。 注目すべき変更を加えたら、必ずコミットに記録してください。 一般的なアプローチは、ローカルで頻繁にコミットを行い、リモートにプッシュする前にリベースによってそれらをスカッシュすることです。 これにより、柔軟なコミットが可能になり、コミット履歴もシンプルに保たれます。

コミットと貢献者の多い大規模なプロジェクトでは、main ブランチの履歴にプロジェクト全体よりもトピック ブランチの開発が反映されてしまうことがあります。 Git では、コミットのスカッシュとリベースにより、ブランチ上のコミットを統合できます。 コミットをスカッシュすると、ブランチの履歴が冗長にならず、マージ後の main ブランチのコミット履歴がシンプルになります。

git blame コマンドを使用して、ファイルに対して特定の変更を行ったユーザーを確認します。 ローカル リポジトリから、 目的の行を指定する -L パラメーターを使用して、git blame を実行できます。 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 ではユーザーの変更が誤って失われないようにするために、チェックアウトが実行されるのを防ぎます。 2 つのオプションがあります。

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

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

Git LFS (Large File Storage) は大きなバイナリ ファイルの保存に推奨されています。Git LFS によりマージ競合を回避できるだけでなく、複製およびプッシュ時間に影響するリポジトリ全体のサイズも管理できます。

変更をコミットせずに保存する場合は、Git stash を使用します。 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] は競合していないファイルの変更を復元し、競合しているファイルには競合マーカーを作成します。 この場合は、変更を手動でマージする必要があります。

stash が完了したら、[git stash drop] で削除します。 このコマンドは、最後にスタッシュした変更セットを削除します。

複数の stash を作成できますが、stash の適用や削除を明示的に行わなければならず、管理により多くの手動操作が必要になります。 詳細については、Git stash のドキュメントを参照してください。

既定では、コマンド ライン Git でコミット メッセージの入力やリベースの実行、その他の追加情報が必要な作業を行うとき、コマンドライン エディターが使用されます。 既定のエディターは、git config を使用して構成されます。

> git config core.editor _path_to_editor_ _options_to_editor_

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

> git config core.editor notepad

このコマンドでは、必要に応じて Git 情報を編集し、Git からメモ帳にテキストを適切に渡すように Windows のメモ帳を構成します。 次のように指定することもできます。

> git config format.commitMessageColumns 72 

コミット メッセージ内のテキスト列が 72 文字の設定に保持され、1 行の文字制限に達した後で行を折り返します。

Git では、各コミットにユーザー名と電子メール アドレス情報が配置され、Azure Repos ではコミットを表示するときや pull request を操作するときに、この情報を使用します。 コマンド ラインで作業している場合は、git config コマンドを使用して、表示される名前と電子メール情報を更新できます。

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

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

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

Visual Studio 2019 バージョン 16.8 以降のバージョンでは、チーム エクスプローラーの Git ユーザー インターフェイスが維持される一方、Git バージョン コントロール エクスペリエンスが提供されます。 [チーム エクスプローラー] を使用するには、メニュー バーで [ツール]>[オプション]>[プレビュー機能]>[New Git user experience](新しい Git ユーザー エクスペリエンス) のチェック ボックスをオフにします。 どちらのインターフェイスからも Git 機能を同じように実行できます。

[チーム エクスプローラー] で [設定] を選択し、[Git] で [グローバル設定] または [リポジトリ設定] のリンクを選択します。