Gitシリーズ解説(5)：Git共通コマンド整理

Git シリーズの前の記事では基本について詳しく説明しましたが、Git には他にも多くのコマンドが含まれているため、それぞれについては詳しく説明しません。この記事では、将来の参考のために、バージョン 2.0 以降でよく使用される Git コマンドをいくつか整理します。 .忘れてください。

1. リポジトリを作成する

1.1 git clone <url> <local path>
コードやバージョンの送信レコードなどを含むリモート バージョン ライブラリを、ローカルで指定されたパスに複製します。
ローカル パスが後で追加されない場合は、次の方法で現在のディレクトリに複製されます。デフォルト、およびウェアハウスが配置されているディレクトリ これはリモート ウェアハウスの名前と呼ばれます; Git シリーズの説明 (1):コード ホスティング プラットフォーム GitCode の使用とローカル Git 環境の構築を
参照してください。

• git clone -n​​ <url> <local path> は
  チェックアウト操作を実行しません。つまり、クローンを作成するだけです.git。後でコードをチェックアウトしたいときに直接使用できますgit checkout HEAD。

1.2 git init <ウェアハウス名> は
git ウェアハウスを初期化します。実行後、ディレクトリの下に.gitディレクトリが表示されます。現在のデフォルトは master ブランチです。

• git init --bare <ウェアハウス名> git bare (bare) ウェアハウスを初期化します
  (1)以下の図を見てください。 git bare ウェアハウスのディレクトリ構造は、bareproject.git上記の gitwarehouse の.gitディレクトリ構造と同じであり、同等です。通常の gitwarehouse .git ディレクトリにコピーされますが、ワークスペースがないため、git 関連の操作 (git add/push/commit など) は無効になります。ベアウェアハウスの意義は、各クライアントから提出されたバージョン情報などを保管するgitのセントラルウェアハウスとしてサーバー上で利用することです。
  
  (2)ベア ウェアハウスを作成する場合、通常、名前は .git で終わります。これが、gitcode などのコード ホスティング プラットフォームから git クローンされたプロジェクトがすべて .git で終わる理由を説明しています。
  

---

2. 変更と提出

2.1 git status
ワークスペースおよび一時ストレージ領域内のファイルのステータス (変更、削除、追加されたファイル、追跡されていないファイルなど) を表示します。

2.2 git diff
一時記憶域に記録された変更をワークスペース内の追跡ファイルと比較して表示します。つまり、ファイルが git add を実行した後、git diff は出力されません。

• git diff <file>特定のファイルの変更を表示する

2.3 git add.
ワークスペース内のすべてのファイルの変更レコードを一時記憶領域に追加します (ファイルの更新、削除、新規作成などのレコードを含み、git 1.0 以降のバージョンの git add -A と同じです)。

• git add <file> は、ワークスペース内のファイル変更レコードを一時記憶域に追加します。
• git add -u は、追跡されたファイル変更レコードを一時記憶域に追加するだけです

2.4 git rm <file> は、
ワークスペース内のファイルを削除し、削除レコードを一時記憶域に追加します。これは、以下と同等です。rm <file> + git add <file>

• git rm <file> --cached は、
  一時記憶領域にファイルの削除記録を追加しますが、作業領域のファイルは変更されません。その後、git commitそのような操作を実行すると、ファイルはローカル リポジトリまたはリモート リポジトリから削除されます。このコマンドの適用シナリオは通常、ファイルの問題を見つけてリポジトリから削除することですが、後でこのファイルに基づいて変更する必要があるため、ローカル ワークスペースにあるこのファイルは直接削除されません。

2.5 git mv <old name> <new name>
ワークスペース内のファイルの名前を変更し、変更レコードを一時記憶領域に追加します。

2.6 git commit
一時記憶領域に記録されているすべてのファイル（更新、新規、削除）をリポジトリに送信します。.gitこのコマンドを実行すると、ディレクトリ内の COMMIT_EDITMSG ファイルが自動的に開きます（デフォルトでは nano エディタが使用されます）ので、投稿情報を編集した後、保存して終了すると投稿が完了します。

• git commit -m "提出情報" : git commit と比較して、提出記録ファイルは自動的に開かれません。
• git commit --amend : これは以前の提出に対する補足であり、新しい提出情報とコミット ID は以前の提出を上書きします。
• git commit -am "コミット情報" : git add と git commit -m の組み合わせと同等

---

3. コミット履歴を表示する

この部分の内容は Git シリーズ解説(4): レコードのコミットにgit log と gitblame を使う で詳しく説明していますので、ここでは大まかに概要を説明します。

• git log
  git log --pretty=
  git log --oneline
  git log --stat
  git log -p
  git show commitID
  git show --stat commitID
  git log --date=
  gitblame <ファイル>
  gitblame -L <行数開始まで >,<終了行番号> <ファイル>

---

4. 失効

4.1 git replace <commit>
(1) 主な機能は、HEAD ポインタを特定のコミットにリセットすることです。デフォルトの効果は次と同じですgit reset --mixed <commit>
(2) ここで<commit>HEAD ポインタを指定することもできます。たとえばgit reset HEAD、これは、コミットにリセットすることを意味します。 HEAD が指すコミット (つまり、最新の送信)
(3) 追跡されていないファイル (git add のないファイル) は影響を受けないことに注意してください。これは、以下のすべてのオプションに適用されます。

• git replace --soft <commit>
  ワークスペースと一時ストレージ領域は変更されず、リポジトリは特定のコミットにリセットされます。
• git replace --mixed <commit>
  ワークスペースは変更されず、一時記憶領域とバージョン ライブラリを特定の送信にリセットします。
• git replace --hard <commit> は
  作業領域、一時記憶領域をリセットし、コミットされていないコンテンツはクリアされます。
• git replace --merge <commit> では
  、このオプションを 2 つの場合に分けて説明しています。 (1) ワークスペース内の未変更のファイルと、一時記憶領域に追加された変更されたファイル。この部分の処理は、ワークスペース内のファイル
  の処理と同じです。–hardワークスペース、一時記憶領域とバージョンライブラリのすべてがリセットされます;
  (2) 一時記憶領域に追加されていない変更されたファイルについては、この部分の処理は同じであり–mixed、これらのファイルはリセットされませんワークスペースに保存すると、変更は引き続き保持されます。次の図に示すように、ファイルのこの部分を正常にリセットできずに終了するケースが 2 つあります。
  
  1 つ目のケース: リセット送信にこのファイルが含まれていない
  
  2 つ目のケース: リセット送信にこのファイルが含まれているにありますが、そのコミットはそれを変更した最新のコミットではありません。
  
• git replace --keep <commit>
  これは–mergeオプションに似ていますが、一時記憶域に追加されたファイルも 2 つの異常な状態の影響を受ける点が異なります。

4.2 git checkout
このコマンドには、ブランチを切り替える機能に加えて、失効の目的を達成するためにファイルをチェックアウトする機能もあります。ファイルは影響を受けないことに
注意してください。未跟踪已跟踪未提交过

• git checkout HEAD .
  作業領域、ステージング領域、リポジトリを比較し、ローカル リポジトリ (現在のブランチ) から現在のディレクトリ内のすべてのファイルをチェックアウトし、ワークスペースとステージング領域を上書きします。
• git checkout と .
  のgit checkout HEAD .違いは、一時記憶領域と作業領域の差分のみを比較するため、git add で実行したファイルはこのコマンドではチェックアウトされません。 git で追加されたファイルは、使用できますgit checkout HEAD .
• git checkout HEAD <file>
  は作業領域を比較し、一時記憶領域はバージョン ライブラリとは異なり、ローカル バージョン ライブラリ (現在のブランチ) からファイルをチェックアウトし、作業領域と一時記憶領域を上書きします。
• git checkout <file>
  とgit checkout HEAD <file>の違いは、一時記憶領域と作業領域の差分を比較するだけなので、git add で実行したファイルはこのコマンドではチェックアウトされません。 git によって追加されたファイルを出力し、使用できますgit checkout HEAD <file>

4.3 git revert <commit>
が異なりますgit reset <commit>。 git revert は新しいコミットを生成します。このコミットの機能は、既存のコミットのすべての変更を元に戻すことです。head は新しく生成されたコミットを指します。これは基本的に元に戻されるか取り消されます。

• git revert -n <commit>
  プラス-nオプションはコミットしないことを意味するため、-n を追加した場合は、git revert の後に手動で git commit を実行する必要があります。

---

5. ブランチとタグ

5.1 git ブランチには
すべてのローカル ブランチが表示されます

• git Branch -a は、
  すべてのローカルおよびリモート ブランチ名を表示します。通常は -v または -vv とともに使用されます。
• git Branch -v は、
  ローカル ブランチ名、コミットの短縮ハッシュ、およびコミット コメントを表示します。その場合-vv、ローカルブランチに対応するリモートブランチの名前がさらに表示されてもよい。
• git Branch -r は
  すべてのリモート ブランチ名を表示します
• git Branch <新しいブランチ名> は
  新しいローカル ブランチを作成します
• git Branch -d <ブランチ名> は
  ローカル ブランチを削除します。マージされていないブランチは削除できません
• git Branch -D <ブランチ名>
  ローカル ブランチを強制的に削除します。使用には注意してください

5.2 git tag は
すべてのローカルタグをリストします

• git tag <タグ名> は
  最新のコミットに基づいてタグを作成します
• git tag -a <タグ名> <コミット ID>
  コミットに基づいてタグを作成します
• git tag -d <タグ名>
  ローカルタグを削除します

5.3 git checkout <branch / tag>
指定したブランチまたはタグに切り替える ただし、直接使用するとgit checkout <tag>先頭ポインタが分離されるため、通常はこのような使い方はしない。

• git checkout -b <新しいブランチ> は
  ブランチを作成し、このブランチに切り替えます
• git checkout -b <新しいブランチ> <古いブランチ>
  既存のブランチに基づいて新しいブランチを作成し、このブランチに切り替えます
• git checkout -b <新しいブランチ> <タグ>
  タグのコミットを最新のコミットとして取得し、新しいブランチを作成して、このブランチに切り替えます。次の例に示すように:
  

---

6. マージとリベース

6.1 git merge <branch> は、
指定されたブランチを現在のブランチにマージします。

6.2 git rebase <branch>
リベース操作。たとえば、下図に示すように、現在作業ブランチにある場合、 を実行するには、git rebase masterまず 2 つのブランチの共通の親ブランチ C2 を見つけ、次に作業ブランチ上の C2 以降のブランチ (つまり W3) をインターセプトします。 W3 のベース ブランチをマスター ブランチ ブランチの最新のものに変更すると、この変更のプロセスには W3' を形成するためのマージ プロセスが含まれます。

ここでリベースの意味についてお話しする必要がありますが、個人的には、リベース操作とマージ操作は両方とも 2 つのブランチをマージする機能を持っていますが、リベースは非常に明確なコミット履歴を形成でき、ブランチ上でのフォークは発生しないと考えています。ブランチグラフです。詳細は別記事Gitシリーズ解説(3)：同一ブランチ配下の複数人共同開発を参照してください。

このようなメリットがあるリベースですが、ブランチグラフ上でマージした際に反映できないという致命的な欠点があり、git mergeなら反映できるのですが、確かにgit rebaseの操作はやや複雑で、企業ではほとんど利用されていません。一般に。ブランチ グラフは乱雑になり、自動的にマージされた送信情報が大量に存在しますが、一般的な状況は無害です。最終的に git rebase を使用するかどうかは、実際の状況を考慮してください。

6.3 git Cherry-pick <commit>
Cherry-pick は、名前が示すように、コミットを抽出して現在のブランチにハングすることです。マージやリベースに比べて柔軟性が高く、投稿されたコンテンツから使いたいものを厳選して利用できるのが利点です。

• git Cherry-pick <commit 1>…<commit n>
  Cherry-pick は範囲抽出をサポートしています。左側のコミット時間は右側のコミット時間よりも早く、選択された範囲は左側が開いており、右側が閉じていることに注意してください。一番入れたいのは左側のコミットも正常に取得できたので、次のように書く必要がありますgit cherry-pick <commit 1>^…<commit n>

• git Cherry-pick -e は
  送信プロセスの情報を編集できます

• git Cherry-pick -n は
  コミット操作を自動的に実行しませんが、ワークスペースと一時記憶域のコンテンツを更新するだけであり、git commit後で手動で変更をリポジトリに送信するために使用できます。

• git Cherry-pick -x は、
  コミット情報の後に「(cherry pick from commit xxx)」という行を自動的に追加し、このコミットがcherry-pickからのものであることを強調します。

• git Cherry-pick -s は、
  コミット情報の後に「(Signed-off-by: xxx)」という行を自動的に追加し、誰がこのコミットをチェリーピックしたかを強調します。

• git Cherry-pick -m <num>
  一部のコミットは 2 つのブランチからマージされ、このコミットには 2 つの親があります。チェリーピックは実際には、ターゲットのサブミッションと親のサブミッションの差分パッチで動作するため、チェリーピックなどのマージサブミッションが行われるときに、差分パッチとして使用する親とターゲットのサブミッションを指定しないと、チェリーピックが行われます。 -pick は失敗します。この-mオプションでは、差分パッチにどの親を使用するかを指定できます。2 つの親はそれぞれ No. 1 と No. 2 で表され、No. 1 の親は現在のブランチでのサブミッションを表し、No. 2 の親は現在のブランチでのサブミットを表します。マージされたブランチ所以这个数值一般指定为1。

---

7. 遠隔操作

7.1 git remote -v リモート
リポジトリ情報の表示 (リモート リポジトリ名とウェアハウス アドレスを含む)

• git remote show <remote>
  指定されたリモート リポジトリ情報を表示します。たとえば、git remote show origin

• git remote add <remote> <url> は
  リモート ウェアハウスを追加します。このコマンドは新しいプロジェクトに適用できます。このコマンドを使用してリモート ウェアハウスの名前と URL アドレスを追加し、コマンドを通じてgit push <remote> <branch>ウェアハウス情報をサーバーに送信すると、リモート サーバー上にウェアハウスとブランチが作成されます。 。

7.2 git fetch <remote> <branch>
リモート ウェアハウスの更新情報を取得し、その情報をローカルのリモート ウェアハウスのコピーに更新します。git fetch を使用した後、実際の状況に応じてローカル ウェアハウスとマージするかどうかを決定できます。

7.3 git pull <remote> <branch> は
リモート ブランチ コードをプルし、ローカル ブランチ コードにマージします。これは以下と同等です。git fetch + git merge

7.4 git Push <remote> <branch>
git commit を使用してローカル ウェアハウスに送信した後、このコマンドを使用して、ローカル ウェアハウスの送信情報 (コード、インデックス、送信レコードなど) をリモート ウェアハウスにプッシュします。もちろん、このコマンドは、新しく作成されたローカル リモート ブランチ、リモート ウェアハウスなどをプッシュすることもできます。リモート支店とリモート倉庫をローカルに作成する方法については、前のコンテンツを参照してください。

• git Push <remote> :<branch / tag> は、
  リモート ウェアハウスのブランチまたはタグを削除します

7.5 git Push --tags
すべてのローカル タグをアップロードします

---

8. キャッシュ変更（git stash）

まず 2 つのシナリオについて説明します:
 
シナリオ 1:ある機能が dev ブランチで開発されているときに、解決する必要があるバグが突然発生しました。このとき、バグ修正ブランチに切り替えてバグを修正すると、 dev ブランチの下の変更は失われますが、現時点ではコードが完成していないため、まだコミットしたくありません。何をすべきか？
 
シナリオ 2:喜んでコードを書いたのですが、突然、間違ったブランチを書いて、bugfix ブランチに書いたことに気づきました。コードを修正して dev ブランチに変更するにはどうすればよいですか?
 
上記 2 つのシナリオは、提出には適さないベースに基づいていますが、現在の変更を保持したい場合、ファイルをバックアップしない方法はありますか? 心配しないでください。git は git stash キャッシュ メカニズムを提供します。

git stash は、
ワークスペースの変更されたコンテンツ (以前に git によって追加された、git によって管理されるファイルであることに注意してください) をキャッシュに追加します。実行が完了すると、キャッシュにレコードが 1 つ増え、現在のワークスペースで変更されたコンテンツはクリアされます。git stash が実行されるたびに、キャッシュに追加のレコードが作成されます。このキャッシュはデータ構造のスタックに似ており、後入れ先出しの原則が維持されます。これは git stash について話すときに理解されます。以下にポップします。

git stash save "comment" は
git stash と同じですが、コメント レコードが 1 つ増えており、後で表示して理解するのに便利です。

git stash list
キャッシュリストの表示

git stash Pop が
このコマンドを実行すると、キャッシュ内の最後 (最新) の変更がワークスペース ファイルに上書きされ、このキャッシュもキャッシュ内でクリアされます。キャッシュはスタックに似ていると上で述べましたが、このコマンドはそれを反映できます。

git stash apply stash@{index}
キャッシュ内のレコードをワークスペースに上書きする場合は、このコマンドを使用できます。実行後、キャッシュは自動的にクリアされません。例えばgit stash apply stash@{1}

git stash show stash@{index}
現在のワークスペースファイルと特定のキャッシュの差分を表示しますが、表示できるのは差分の数のみで、具体的な差分内容は表示できません。

git stash drop stash@{index} は、
特定のキャッシュを破棄/クリアします。このキャッシュをクリアした後、後続のキャッシュ インデックスは自動的に 1 つ減ります。

git stash clear は
すべてのキャッシュをクリアします

したがって、上記の 2 つのシナリオの問題は解決されます。
 
シナリオ 1: bugfix ブランチを切り替える前に、git stash キャッシュを使用してワークスペースを変更し、次にバグフィックスに切り替えて問題を修正し、その後 dev ブランチに戻ってキャッシュをワークスペースに上書きして開発を続行します
 
。ブランチ上のコードを編集する場合は、現在のワークスペースのキャッシュを変更してから、正しいブランチに切り替えて、 git stash Pop または git stash apply stash@{index} を実行するだけで済みます。

---

9. 作業ツリー (git worktree)

前述の git キャッシュ メカニズムは確かに使いやすいですが、一部のシナリオには適用できません。
 
シナリオ 1:たとえば、A ブランチの問題を修正してコンパイルしていると、コンパイルに時間がかかることがあり、コンパイルが完了するまで待ってから他のブランチの開発タスクに進むことができます。
 
シナリオ 2:たとえば、Beyond Compare ソフトウェアを使用して 2 つのブランチ コードを比較したいと考えていますが、このソフトウェアは 2 つのディレクトリ内のファイルしか比較できません。
 
誰かが、複数のコード ウェアハウスをローカルに複製することでこのコード セットを解決できると提案しましたが、問題は、コードの変更と共有を複数のコード ウェアハウス間で直接実行できないことです。ウェアハウス A で変更されたコードはサーバーに送信する必要があり、次に、ウェアハウス B は、サーバーのコンテンツをプルプルするなどの git コマンドを渡して、ウェアハウス A の変更されたコンテンツを取得できますが、これは少し面倒です。
 
このような状況に備えて、git は新しいワークスペース (ディレクトリ) を作成するためのワーク ツリー機構を提供します。作成されたこれらのワークスペースは同じローカル バージョン ライブラリを使用します。ワークスペースを作成するときに、管理するブランチを指定します (新しいブランチを作成することもできます)。作成した）。

9.1 git worktree add <作業ツリーのパス> -b <新しいブランチ> <古いブランチ>
元のブランチに基づいて新しいブランチを作成し、新しいブランチに基づいて作業ツリーを作成します。
ヒント: 新しいブランチの名前に temp プレフィックスを追加して、このブランチが一時的なものであることを強調することをお勧めします。

• git worktree add <ワーキング ツリー パス> は、
  ワーキング ツリー ディレクトリの名前で新しいブランチを作成します。この新しいブランチは、現在のブランチ (または現在のヘッド ポインターの位置) に基づいて作成されます。
  注: サブモジュールを含む作業ツリーが作成された後、新しく生成された作業ツリー ディレクトリのサブモジュールは空になるため、サブモジュールを再同期する必要があります。

• git worktree add <作業ツリーのパス> -b <新しいブランチ> は、
  作業ツリーを作成するための新しいブランチ名を指定します。新しいブランチは、現在のブランチ (または現在のヘッド ポインターの位置) に基づいて作成されます。

• git worktree add <作業ツリーのパス> <古いブランチ>
  このコマンドは、元のブランチを直接使用して新しい作業ツリーを作成します。

9.2 git worktree list は
、作業ツリーのパスとそれに対応するコミット ハッシュ値とブランチ名 (またはヘッド ポインターのステータス) を含むすべての作業ツリーをリストします。

9.3 git worktree delete <ワーキング ツリー パス>
ワーキング ツリー ディレクトリを削除します (サブモジュールを含むワーキング ツリーは削除できません)。ただし、対応するブランチは削除されず、後で手動で削除できます。

• git worktree delete <ワーキング ツリー パス> --force は
  上記と似ていますが、サブモジュールを含むワーキング ツリー ディレクトリも削除できる点が異なります。

9.4 git worktree move <ワーキング ツリー パス> <新しいワーキング ツリー パス>
ワーキング ツリー ディレクトリを別の場所に移動 (または名前変更) します。サブモジュールを含むワーキング ツリーはこの操作を実行できません。

9.5 git worktree lock <作業ツリーのパス>
特定の作業ツリーをロックします。ロック後は、この作業ツリーに対してgit worktree move、git worktree remove、およびその他の操作を実行できなくなります。git worktree prune

9.6 git worktreeunlock <作業ツリーパス>
作業ツリーのロックを解除します

9.7 git worktree prune は、
git worktree delete によって作業ツリーを削除しない場合がありますが、rm などのコマンドを使用して作業ツリー ディレクトリを直接削除します。これにより、作業ツリーの情報がディレクトリ内に残り、prune コマンドを使用してクリアされます.git/worktrees。この部分は役に立たない情報です。