よく寄せられる Git の質問

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

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

受け入れられる方法は、論理的に別々の変更に対して別々のコミットを行うことです。 コミットをログブックのエントリと考えてください。 注目に値する変更を行うたびに、コミットに記録します。 一般的なオプションは、すべてのユーザーが必要なだけローカルでコミットできるようにし、ローカル コミットをプッシュする前に、リベースを通じてこれらをスカッシュすることです。 このオプションを使用すると、コミットを頻繁に行う柔軟性をユーザーに提供しつつ、コミット履歴の合理化を維持することができます。

コミットが多く、多数の共同作成者からなる大規模なプロジェクトでは、main にマージされるトピック ブランチの開発履歴である main ブランチのコミット履歴が、プロジェクト全体の開発履歴よりも多くなる可能性があります。 Git では、コミットのスカッシュとリベースを通じてブランチのコミットを圧縮するための機能が提供されています。 コミットをスカッシュすると、ブランチのコミット履歴の詳細度が低くなり、マージ後にメイン ブランチでのコミット履歴が簡単になります。

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

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

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

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

Git で別のブランチにチェックアウトすると、ファイル システム上のファイルの状態に影響します。 Git ではコミット履歴を使用して、ブランチの状態を表すファイルが確実に使用されるようにします。 コミットされていない変更がある間にブランチを変更しようとすると、それらの変更はチェックアウト中に上書きされます。 Git ではユーザーの変更が誤って失われないようにするために、チェックアウトが実行されるのを防ぎます。 2 つのオプションがあります。

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

変更を保持したいが、コミットすることに納得していないため、コミットしたくない場合があります。 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 スタッシュのドキュメントを参照してください。

既定では、コミット メッセージの要求やリベースの実行、実行するために追加情報を必要とする他の作業を行うとき、コマンド ライン 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 "frank@fabrikam.com"
> git config --global user.name "Francis Totten"

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

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

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

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