常用系列は、自分がプログラミングでよく使うものを記録するものであり、この記事は常用系列の第 2 篇で、日常的に使用する Git コマンドを記録し、必要なときに参照できるようにするためのものです。Git は GUI インターフェースを提供していますが、私は Git の GUI ソフトウェアが多くあると思いますが、最も一般的なコマンドを習得することは、優れたプログラマーが行うべきことです。結局のところ、コマンドはどこでも同じですが、GUI ソフトウェアがいつ使えなくなるかもしれません🐶、また、コマンドラインモードでは Git のすべてのコマンドを実行できます。
Git の最も基本的な操作#
ファイルをローカルからリポジトリに移動するプロセス：以下は、どのコマンドを使用してファイルをローカルからリモートリポジトリにプッシュできるかを記録しています。これを基本操作と呼びます。
Git のインストール#
Mac コンピュータに Git をインストールしたい場合は、git のバージョンを確認するコマンドを入力するだけで、インストールを促されます（以前にインストールしていない場合）。
git --version
ユーザー情報の設定#
Git をインストールした後、Git の環境を設定します。これらの設定は各コンピュータで一度だけ行えばよく、もちろん設定後に変更することもできます。Git で最も一般的な設定は、ユーザー名とメールアドレスの設定です。
--globalは、システム上のすべてのリポジトリに対して有効であることを示します。
# ユーザー署名を設定します。 .gitconfigファイルで確認できます。
git config --global user.name <ユーザー名>
# ユーザーのメールアドレスを設定します。 .gitconfigファイルで確認できます。
git config --global user.email <登録gitリポジトリメール>
Config には 3 つのスコープがあります：明示的に設定しない場合はデフォルトで local
- local：特定のリポジトリにのみ有効
- system：システム上のすべてのログインユーザーに有効
config の設定を表示#
git config --list --local
git config --list --global
git config --list --system
Git リポジトリの取得#
通常、リポジトリを取得する方法は 2 つあります：
- ローカルディレクトリを Git リポジトリに変換する
- 他の場所からリポジトリをコピーしてローカルに持ってくる
既存のディレクトリでリポジトリを初期化#
git init
このコマンドは、現在のディレクトリに.gitディレクトリを作成し、その中に初期化されたリポジトリのすべてのファイルを含みます。
リポジトリをクローン#
git clone https://github.com/libgit2/libgit2
このコマンドは、リモート GitHub の libgit2 リポジトリからすべてのものを現在のディレクトリにプルします。
ファイルの状態を記録#
ファイルの状態には 2 種類あります：追跡されている、追跡されていない。追跡されているとは、現在 Git がこのファイルのすべての変更（変更、削除、名前変更）を記録できることを意味します。
ファイルの状態を確認#
git status
# 簡潔にファイルの状態を出力します。A-一時的な領域に追加、M-変更されたファイル、D-削除されたファイル、R-名前変更されたファイル、??-追跡されていないファイル
git status -s
新しいファイルを追跡#
# 以下のコマンドを使用した後、一般的にはgit statusを使用してファイルが追跡されているか確認します。
git add <ファイル名>
# 一時的な領域に追加するすべてのファイルを一時的な領域に追加します。
git add . / git add -A
# すでにGitによって追跡されているファイルの変更を一時的な領域に追加します（追跡されていないファイル、つまり新しいファイルは含まれません）。
git add -u
このコマンドを使用すると、ファイルは Git の一時的な領域に追加されます。一時的な領域内のファイルは、リモートリポジトリにプッシュされる候補者です。
差分を比較#
一時的な領域にあるファイルと未追跡のファイルの違いを比較します。
通常、ファイルを多く変更した場合、どのファイルが変更されたかを忘れやすくなります。このとき、どのような変更を行ったかを確認するために
diffコマンドを使用します。
# ファイルは一時的な領域にあり、追跡されている必要があります。
git diff <ファイル名>
# ファイル名を指定しない場合は、作業ディレクトリと一時的な領域の違いを比較します。
git diff
一時的な領域内のファイルと前回のコミット時のファイルの違いを比較したい場合は、以下のコマンドを使用できます。
git diff --cached
異なるコミット間の違いを比較することもできます。
git diff <コミットID0> <コミットID1>
# 2つのコミット間の特定のファイルの違いを比較する場合は、--を追加します。
git diff <コミットID0> <コミットID1> -- [ファイル名]
ファイルとフォルダの名前変更#
git mv は、Git でファイルまたはフォルダの名前を変更または移動するためのコマンドです。
# このコマンドは、ファイルを古いパスから新しいパスに移動し、この変更をGitの一時的な領域に追加します。
git mv <古いファイル名> <新しいファイル名>
更新をコミット#
一時的な領域に今回コミットしたいファイルが含まれている場合、
commitコマンドを使用してファイルの変更をコミットできます。
# 各commitは一時的な領域をクリアします。
git commit -m "<ダブルクォーテーション内には今回のコミットファイルの説明情報を記入します>"
ファイルをリモートにプッシュ#
リモートリポジトリを追加#
リモートリポジトリからクローンしたファイルでない場合、ローカルで自分で作成した Git リポジトリの場合、リモートリポジトリにプッシュする前にプッシュするリポジトリを追加する必要があります。
git remote add https://github.com/paulboone/ticgit
プッシュ#
git push origin master
このコマンドは、master ブランチのコードをリモートの origin サーバーにプッシュすることを示します。
これで、ファイルが作成されてから最終的にリモートリポジトリに同期されるプロセスが完了しました。
次に、Git を使用する過程で遭遇したいくつかの状況で使用するコマンドを記録します。
コミット操作#
前回（最近の）コミットを修正#
- 前回のコミットの情報を修正
- 前回のコミットに基づいて再度変更またはファイルを追加
これらの状況では、以下のコマンドを使用できます。
# このコマンドは前回のコミットに基づいており、新しいコミットは生成されません。
git commit --amend
クエリ#
ここでは、Git のシナリオでさまざまな必要なクエリを記録します。
コミット履歴を確認#
プロジェクト全体の履歴コミット記録#
git log
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <[email protected]m>
Date: Mon Mar 17 21:52:11 2008 -0700
バージョン番号を変更しました
commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
Author: Scott Chacon <[email protected]m>
Date: Sat Mar 15 16:40:33 2008 -0700
不要なテストを削除しました
# 過去のすべてのコミットを1行形式で表示
git log --pretty=oneline
# ブランチのコミットグラフ
git log --graph
git log --graph --pretty=oneline --abbrev-commit
# 最近K回のコミットのみを表示
git log -n K
出力される内容は次のとおりです：
- 各コミットの SHA-1 チェックサム
- コミット者の名前
- メールアドレス
- コミット日時
- コミットメッセージ
ファイルの履歴コミット記録#
単一のファイルの各コミット記録を確認します。
git log -p <ファイル名>
# 最近の2回のコミットのみを表示
git log -p -2 <ファイル名>
各行のコミット記録#
任意のファイルの各行の最後の変更のコミット記録を表示できます。
git blame <ファイル名>
# 特定の行を表示する制限
git blame -L 69,82 <ファイル名>
バグを探す#
多くの場合、現在のブランチに問題が発生しましたが、どこに問題があるかわからない場合、
git bisectコマンドを使用して、どのコードのコミットがエラーを引き起こしたかを探すことができます。
このコマンドは、二分探索の原理を使用します：
二分【コードに問題がないコミット ~ 現在問題のあるブランチ】の範囲を通じて、問題がある可能性のあるコミットを見つけます。
git bisect startコマンドでエラーを探し始めます。そのフォーマットは次のとおりです：
$ git bisect start [終点] [起点]
終点は最近のコミット、起点は以前のコミットです。これらの間のこの履歴がエラーの範囲です。
どの起点のコミットが問題ないかわからない場合は、最初のブランチを選択できます。
# 終点は現在のブランチHEAD、起点は最初のコミット4d83cf
git bisect start HEAD 4d83cf
上記のコマンドを実行すると、現在のコードはこの範囲の中間のコミットに切り替わります。
その後、現在のコードをテストできます。問題がなければ、以下のコマンドを実行してこのコミットを良好としてマークします。
git bisect good
問題がない場合、エラーはコードの履歴の後半に導入されたことを意味します。上記のコマンドを実行すると、Git は自動的に後半の中点に切り替わります。
その後、再度テストを行い、問題がある場合はこのコミットを問題ありとしてマークします。
git bisect bad
ここで終わりではありません。問題があるのは今回だけですが、最初に問題があったコミットを見つける必要があります。
次に、このプロセスを繰り返し、問題が発生したコミットを見つけるまで続けます。この時、Git は次のようなメッセージを表示します。
b47892 is the first bad commit
その後、このコミットでどのファイルが変更されたかを分析し、エラーの原因を分析できます。
注意：コードの欠陥は自分で判断する必要があり、Git はどこに問題があるかを分析することはできません。
その後、git bisect resetコマンドを使用してエラーを探すのを終了し、最近のコードのコミットに戻ります。
内容を探す#
Git は Linux コマンドと同様に、
grepと組み合わせて使用できます。
git grep -n ""
取り消し#
Git を操作していると、エラーが発生することが避けられません。エラーを修正する方法は、一般的には再度修正するか、問題がない状態に戻すことです。
ファイルの取り消し#
作業ディレクトリの操作#
- 一時的な領域に追加されていない変更をすべて取り消します。
# -- 非常に重要です。--がない場合、「別のブランチに切り替える」コマンドになります。
git checkout -- <ファイル名>
# 一時的な領域のすべてのファイルを作業ディレクトリに戻します。
git checkout .
# 特定のコミットのファイルを一時的な領域と作業ディレクトリに戻します。
git checkout [commit] [file]
- 作業ディレクトリの変更を一時的な領域に対して取り消します。一時的な領域に対応するファイルがない場合は、HEAD が指すバージョンに戻ります。
git restore <ファイル名>
一時的な領域の操作#
- 一時的な領域のファイルの変更を取り消します（unstage）、作業ディレクトリに戻します。
git reset HEAD <ファイル名>
# ファイル名を指定しない場合は、一時的な領域のすべてのファイルを作業ディレクトリに戻します。
git reset HEAD
バージョンの取り消し#
コミットバージョン後、リモートで競合が発生し、ブランチをマージできない場合、
git resetを使用してバージョンを戻し、競合を処理した後に再度プッシュします。
# コミットされたコードベースを前のバージョンに戻します。
git reset --hard HEAD^ または git reset --hard HEAD~
# 2つ前のバージョンに戻ります。以下同様です。
git reset --hard HEAD^^：
# 100バージョン前に戻ります。
git reset --hard HEAD~100：
# 特定のバージョンに戻ります。バージョン番号は最初の7桁で、git reflogを使用して確認できます。
git reset --hard バージョン番号：
スタック操作#
開発中に、ある要求が一定の程度まで進んでおり、ローカルコードが多く変更されているが、突然緊急に処理する必要があるバグが発生した場合、すでに変更されたコードは Git のスタックに保存することができます。バグが処理された後、現場に戻って要求の開発を続けます。
# ローカルの変更をスタックに保存します。
git stash
# スタックの状況を確認します。
git stash list
# スタックの最上部の変更を復元しますが、スタックの情報は削除されません。
git stash apply
# スタックの最上部の変更を復元し、同時にスタックの情報を削除します。
git stash pop
ブランチ操作#
ブランチの基本操作#
# すべてのローカルブランチをリスト表示し、現在のブランチの前に*が表示されます。
$ git branch
# すべてのリモートブランチをリスト表示
$ git branch -r
# すべてのローカルブランチとリモートブランチをリスト表示し、ブランチ情報を詳細に表示します。
$ git branch -av
# 新しいブランチを作成し、そのブランチに切り替えます。
$ git checkout -b [branch]
# 指定されたブランチに切り替え、作業ディレクトリを更新します。
$ git checkout [branch-name]
# 前のブランチに切り替えます。
$ git checkout -
# ブランチを削除します。削除するブランチの変更が上流ブランチにマージされている必要があります。そうでない場合、削除に失敗します。
$ git branch -d [branch-name]
# 警告を無視して強制的にブランチを削除します。
$ git branch -D [branch-name]
マージ#
2 つのブランチをマージするために使用されます。
# 指定されたブランチを現在のブランチにマージします。
$ git merge [branch]
リベース#
ブランチのマージにも使用されます。
ブランチのマージ操作は、基本的にマージと同じです。
# 指定されたブランチを現在のブランチにマージします。
git rebase [branch]
もし git rebase が競合に遭遇した場合：
- 最初に手動で競合を解決し、新しく変更されたファイルを一時的な領域に追加します
git add . - その後、
git commitは必要なく、直接git rebase --continueを実行します。
git mergeとgit rebaseの違いは何でしょうか？
git mergeが完了した後は、マージ前のブランチが表示されますが、git rebaseが完了した後は、以前のマージのブランチ記録は表示されません。- ブランチのマージの順序も異なります。
詳細はこのブログを参照してください git merge と git rebase 小結
チェリーピック#
指定されたコミットを現在のブランチにマージします。
# 1つのコミットを選択し、現在のブランチにマージします。
git cherry-pick [commit]
# 複数のコミットを現在のブランチにマージします。
git cherry-pick <HashA> <HashB>
# 一連のコミットをマージします。AコミットはBよりも早く、コミットAは今回のコミットには含まれません。
git cherry-pick A..B
# 一連のコミットをマージします。AコミットはBよりも早く、今回のコミットにはコミットAが含まれます。
git cherry-pick A^..B
もしcherry-pickの過程で競合が発生した場合、手動で競合を解決した後、--continueコマンドを使用してプロセスを続行します。
- コードの競合を解決した後、変更されたファイルを再度一時的な領域に追加します
git add . - 次のコマンドを使用して、Cherry pick プロセスを続行します。
git cherry-pick --continue