次の記事 >
Git と GitHub との連携
[Git]Git の基本
公開日:2025-12-25
更新日:2025-12-25
更新日:2025-12-25
1. 概要
Git の基本です。
Git は、分散型バージョン管理システムで、ファイルの変更履歴を保持して、変更内容の確認などを行うことができます。
Windows で Git を使う場合は、「Git for windows のインストール」を参考にして Git を使えるようにしてください。
Git は、分散型バージョン管理システムで、ファイルの変更履歴を保持して、変更内容の確認などを行うことができます。
Windows で Git を使う場合は、「Git for windows のインストール」を参考にして Git を使えるようにしてください。
2. コマンド一覧
コマンド
git init git の初期化。.git フォルダが作成される。
git add . 全てのファイルをステージングエリアに追加する。変更がない場合や .gitignore のファイルは追加されない。
git add {ファイル名} ファイルをステージングエリアに追加する。
git ls-files --stage ステージングエリアのファイル一覧の表示
git commit -m "メッセージ" git add したファイルをコミットする。
git branch {ブランチ名} ブランチの作成する。
git switch {ブランチ名} ブランチを切り替える。
git merge {ブランチ名} -m "メッセージ" マージする。
git status コミット予定のファイルの確認などが行えます。
git rm {ファイル名} ファイルを削除する。
git rebase {ブランチ名} リベースする。指定されたブランチの後ろに現在のブランチを付け替える。
git rebase --continue リベースでコンフリクト後、リベースを再開する。
git restore {ファイル} ステージングエリアに登録されている状態に戻す。
git restore --staged {ファイル} git add を取り消す。
git reset --hard HEAD 最後のコミットの状態に戻す。
git stash 退避
git stash list 退避リストの表示
git stash apply stash@{0} 退避リストの先頭の状態に戻す。
git stash pop stash@{0} 退避リストの先頭の状態に戻して、退避リストの先頭を削除。{1} は {0} に繰り上がる。
git stash drop stash@{0} 退避リストの先頭を削除。{1} は {0} に繰り上がる。3. リポジトリの作成からコミットまでの流れ
コマンド
# リポジトリの作成
git init
# ファイル作成
echo 'test' > test.txt
# ステージする(コミット対象にする)
git add .
# コミット
git commit -m "作成しました。"
# ファイル修正
echo 'test2' > test.txt
# ステージする(コミット対象にする)
git add .
# コミット
git commit -m "修正しました。"4. ブランチを作成して Fast-Forward マージ
main ブランチから feature ブランチを作成して、
feature でファイルを修正した時のコミットグラフ
main で feature をマージした時のコミットグラフ
main に feature の内容が反映されたように見えます。
これが Fast-Forward マージです。
コマンド
# リポジトリの作成
git init
# ファイル作成してコミット
echo 'test' > test.txt
git add .
git commit -m "作成しました。"
# feature ブランチを作成して切り替え
git branch feature
git switch feature
# feature ブランチでファイル修正してコミット
echo 'test2' > test.txt
git add .
git commit -m "feature で修正しました。"
# feature ブランチでもう一度ファイル修正してコミット
echo 'test3' > test.txt
git add .
git commit -m "feature で修正しました。(2)"
# main に切り替えて、feature をマージ
git switch main
git merge feature -m "feature を main にマージしました"
feature でファイルを修正した時のコミットグラフ
コミットグラフ
test.txt の作成 (main のポインタ)
\
test.txt の修正 -- test.txt の修正2 (feature のポインタ)
main で feature をマージした時のコミットグラフ
コミットグラフ
test.txt の作成 -- test.txt の修正 -- test.txt の修正2 (main のポインタ)
(feature のポインタ)
main で何も変更されていないため、main のポインタを feature と同じ位置に移動するだけで、main に feature の内容が反映されたように見えます。
これが Fast-Forward マージです。
5. マージコミットを作成するマージ
2つのブランチでそれぞれ変更がある時にマージをすると、Fast-Forward マージにならずに、マージコミットが作成されるマージになります。
コミットグラフ
そのため、2つの親コミットを保持するマージコミットを作成して、feature 側のコミットを見れるようにします。
この時、main からは test.txt と test2.txt が見えますが、
feature の位置は変わっていないため、feature から test.txt の修正は見れません。
feature に main で行われた test.txt の修正を反映させたい場合は、feature で main をマージする必要があります。
また、履歴が 2 つに分岐されていますが、この時に feature ブランチを削除しても、
履歴には影響が出ません。feature のコミットが削除される訳ではありません。feature のポインタが削除されるだけです。
コマンド
# リポジトリの作成
git init
# ファイル作成してコミット
echo 'test' > test.txt
git add .
git commit -m "作成しました。"
# feature ブランチを作成
git branch feature
# main ブランチのまま、ファイルを修正してコミット。feature には反映されない。
echo 'test_main' > test.txt
git add .
git commit -m "修正しました。"
# feature ブランチに切り替え
git switch feature
# feature ブランチでファイル作成してコミット
echo 'test_feature' > test2.txt
git add .
git commit -m "feature で作成しました。"
# main に切り替えて、feature をマージ
git switch main
git merge feature -m "feature を main にマージしました"
コミットグラフ
コミットグラフ
test.txt の作成 -- test.txt の修正 ------------------------ マージコミット (main のポインタ)
\ /
test2.txt の作成 (feature のポインタ)
Fast-Forward マージのように、main のポインタを feature の位置に移動してしまうと、test.txt の修正が見れなくなってしまいます。そのため、2つの親コミットを保持するマージコミットを作成して、feature 側のコミットを見れるようにします。
この時、main からは test.txt と test2.txt が見えますが、
feature の位置は変わっていないため、feature から test.txt の修正は見れません。
feature に main で行われた test.txt の修正を反映させたい場合は、feature で main をマージする必要があります。
また、履歴が 2 つに分岐されていますが、この時に feature ブランチを削除しても、
履歴には影響が出ません。feature のコミットが削除される訳ではありません。feature のポインタが削除されるだけです。
6. コンフリクト
2つのブランチで同じファイルの同じ部分を修正してマージした場合、コンフリクト(衝突)が発生して、自動的にマージできなくなります。
最後の git merge でコンフリクトが発生して、test.txt は次のようになります。
「=======」より上が main の修正分、下が feature の修正分です。
コンフリクトが発生した場合は、「=======」などを削除して、手動でテキストファイルを修正します。
ステージングとコミットをして、マージコミットを作成します。
コミットグラフ
コマンド
# リポジトリの作成
git init
# ファイル作成してコミット
echo 'test' > test.txt
git add .
git commit -m "作成しました。"
# feature ブランチを作成
git branch feature
# main ブランチのまま、ファイルを修正してコミット。feature には反映されない。
echo 'test_main' > test.txt
git add .
git commit -m "main で修正しました。"
# feature ブランチに切り替え
git switch feature
# feature ブランチでファイルを修正してコミット
echo 'test_feature' > test.txt
git add .
git commit -m "feature で修正しました。"
# main に切り替えて、feature をマージ
git switch main
git merge feature -m "feature を main にマージしました"
最後の git merge でコンフリクトが発生して、test.txt は次のようになります。
「=======」より上が main の修正分、下が feature の修正分です。
テキストファイル
<<<<<<< HEAD
test_main
=======
test_feature
>>>>>>> feature
コンフリクトが発生した場合は、「=======」などを削除して、手動でテキストファイルを修正します。
テキストファイル
test_main
test_feature
ステージングとコミットをして、マージコミットを作成します。
コマンド
git add .
git commit -m "feature を main にマージしました"
コミットグラフ
コミットグラフ
test.txt の作成 -- test.txt の修正 ----------------------- マージコミット (main のポインタ)
\ /
test.txt の作成 (feature のポインタ)7. リベースでコミットの付け替え
リベースをすると、指定したブランチの後ろに、現在のブランチのコミットを付け替えます。
リベース前
リベース後
これにより、Fast-Forward マージが可能になり、
これを繰り返すことで、分岐がない(マージコミットがない)、一直線の履歴となります。
ちなみに、付け替えられたコミットは、内容は変わりませんが、全てコミット ID が変わるため、C'、G' としています。
リベース前のコミットグラフ
リベース後のコミットグラフ
マージコミットは作成されません。
最新の main のコミットから feature に分岐して開発を進めたのと同じことになります。
ちなみに、コミットの付け替えは、コミットの親コミットを変更することで、付け替えられます。
この時、コミットの親コミット ID を変更すると、自身のコミット ID が変わるため、連鎖してそれ以降のコミットID も変わります。
リベース前
コミットグラフ
A -- B ----- D -- E -- F
\
C -- G
リベース後
コミットグラフ
A -- B -- D -- E -- F
\
C' -- G'
これにより、Fast-Forward マージが可能になり、
これを繰り返すことで、分岐がない(マージコミットがない)、一直線の履歴となります。
ちなみに、付け替えられたコミットは、内容は変わりませんが、全てコミット ID が変わるため、C'、G' としています。
コマンド
# リポジトリの作成
git init
# ファイル作成してコミット
echo 'test' > test.txt
git add .
git commit -m "作成しました。"
# feature ブランチを作成
git branch feature
# main のままファイル作成してコミット
echo 'test' > abc.txt
git add .
git commit -m "abc を作成しました。"
# feature ブランチに切り替え
git switch feature
# feature ブランチでファイル修正してコミット
echo 'test2' > test.txt
git add .
git commit -m "feature で修正しました。"
# もう一度、feature ブランチでファイル修正してコミット
echo 'test3' > test.txt
git add .
git commit -m "feature で修正しました。(2)"
# リベース
git rebase main
リベース前のコミットグラフ
コミットグラフ
test.txt の作成 -- abc.txt の作成 (main のポインタ)
\
test.txt の修正 -- test.txt の修正 (feature のポインタ)
リベース後のコミットグラフ
コミットグラフ
test.txt の作成 -- abc.txt の作成 (main のポインタ)
\
test.txt の修正 -- test.txt の修正 (feature のポインタ)
斜め線で表現してますが、履歴的には一直線で、main の後ろに feature が来ます。マージコミットは作成されません。
最新の main のコミットから feature に分岐して開発を進めたのと同じことになります。
ちなみに、コミットの付け替えは、コミットの親コミットを変更することで、付け替えられます。
この時、コミットの親コミット ID を変更すると、自身のコミット ID が変わるため、連鎖してそれ以降のコミットID も変わります。
8. リベースでコンフリクト
8.1 コンフリクトのコミットが 1 つの場合
コマンド
# リポジトリの作成
git init
# ファイル作成してコミット
echo 'test' > test.txt
git add .
git commit -m "作成しました。"
# feature ブランチを作成
git branch feature
# main のままファイルを修正してコミット
echo 'test_main' > test.txt
git add .
git commit -m "main で修正しました。"
# feature ブランチに切り替え
git switch feature
# feature ブランチでファイル修正してコミット
echo 'test_feature' > test.txt
git add .
git commit -m "feature で修正しました。"
# リベース
git rebase main
リベースでコンフリクトが発生すると、マージの時と同様に、ファイルが次のようになります。
test.txt
<<<<<<< HEAD
test_main
=======
test_feature
>>>>>>> 0c3b0ad (feature で修正しました。)
手動でファイルを修正します。
test.txt
test_main
test_feature
修正したファイルをステージして、--continue を付けて再度リベースします。
test.txt
git add .
git rebase --continue
次のコマンドでリベースを中止することもできます。
test.txt
git rebase --abort8.2 コンフリクトのコミットが複数ある場合
feature で 3 回コミットして、それぞれコンフリクトが発生した場合、その都度解決する必要があります。
最初に、main のコミットと feature の 1 回目の修正のコミットでコンフリクトが発生します。
ファイルを手動で修正して、ステージしてリベースを再開します。
次に、コンフリクトの解決のため修正したファイルと、feature の 2 回目の修正のコミットでコンフリクトが発生します。
ファイルを手動で修正後、ステージしてリベースを再開します。
feature の 3 回目の修正のコミットでもコンフリクトが発生するので、同様に対応します。
コマンド
git init
echo 'test' > test.txt
git add .
git commit -m "作成しました。"
git branch feature
echo 'test_main' > test.txt
git add .
git commit -m "main で修正しました。"
git switch feature
echo 'test_feature_1' > test.txt
git add .
git commit -m "feature で修正しました。1回目"
echo 'test_feature_2' > test.txt
git add .
git commit -m "feature で修正しました。2回目"
echo 'test_feature_3' > test.txt
git add .
git commit -m "feature で修正しました。3回目"
# リベース
git rebase main
最初に、main のコミットと feature の 1 回目の修正のコミットでコンフリクトが発生します。
ファイルを手動で修正して、ステージしてリベースを再開します。
test.txt
git add .
git rebase --continue
次に、コンフリクトの解決のため修正したファイルと、feature の 2 回目の修正のコミットでコンフリクトが発生します。
ファイルを手動で修正後、ステージしてリベースを再開します。
test.txt
git add .
git rebase --continue
feature の 3 回目の修正のコミットでもコンフリクトが発生するので、同様に対応します。
test.txt
git add .
git rebase --continue8.3 複数のコミットをまとめて 1 つにする
リベース時に、何度もコンフリクトが発生する場合があります。
その場合、複数のコミットを 1 つにまとめてからリベースをすることで、コンフリクトによる修正を減らすことができます。
3 つ前のコミットからまとめたい場合は次のコマンドを実行します。
実行するとエディターが起動して、次のように表示されます。
エディターで次のように 2 行目と 3 行目の先頭の pick を squash にして保存すると、1 行目の pick のコミットとまとめられます。
この後で main とリベースをした場合、コンフリクトは 1 回だけになります。
その場合、複数のコミットを 1 つにまとめてからリベースをすることで、コンフリクトによる修正を減らすことができます。
コマンド
git init
echo 'test' > test.txt
git add .
git commit -m "作成しました。"
git branch feature
echo 'test_main' > test.txt
git add .
git commit -m "main で修正しました。"
git switch feature
echo 'test_feature_1' > test.txt
git add .
git commit -m "feature で修正しました。1回目"
echo 'test_feature_2' > test.txt
git add .
git commit -m "feature で修正しました。2回目"
echo 'test_feature_3' > test.txt
git add .
git commit -m "feature で修正しました。3回目"
3 つ前のコミットからまとめたい場合は次のコマンドを実行します。
コマンド
git rebase -i HEAD~3
実行するとエディターが起動して、次のように表示されます。
コマンド
pick ca94169 feature で修正しました。1回目
pick 229d623 feature で修正しました。2回目
pick e1798d7 feature で修正しました。3回目
エディターで次のように 2 行目と 3 行目の先頭の pick を squash にして保存すると、1 行目の pick のコミットとまとめられます。
コマンド
pick ca94169 feature で修正しました。1回目
squash 229d623 feature で修正しました。2回目
squash e1798d7 feature で修正しました。3回目
同じファイルがある場合は、最後のコミットの内容が有効となります。この後で main とリベースをした場合、コンフリクトは 1 回だけになります。
9. 変更の取り消し
現在のステージングエリアに登録されている状態にファイルを戻します。
git add している場合は、ステージングの取り消しを行ってから、再度実行してください。
ステージングのみ取り消す。
最後のコミットの状態に戻す。
コマンド
git restore {ファイル}
git restore .
ファイル修正後に git add すると、git restore しても修正前の状態には戻らないため注意してください。git add している場合は、ステージングの取り消しを行ってから、再度実行してください。
ステージングのみ取り消す。
コマンド
git restore --staged {ファイル}
git restore --staged .
最後のコミットの状態に戻す。
コマンド
git reset --hard HEAD10. 退避
git stash で、変更したファイルを一時的に退避して、変更前の状態に戻すことができます。
また、待機したファイルは、git stash pop や git stash apply に元に戻すことができます。
main ブランチで間違えてファイル修正したものを退避して、feature ブランチで退避した内容を戻します。
また、待機したファイルは、git stash pop や git stash apply に元に戻すことができます。
main ブランチで間違えてファイル修正したものを退避して、feature ブランチで退避した内容を戻します。
コマンド
git init
echo 'test' > test.txt
git add .
git commit -m "作成しました。"
# ファイル変更。但し、本来は、feature で変更するつまりだった。
echo 'test_1' > test.txt
# 変更したファイルを退避して、ファイルを変更前の状態に戻す(まだステージしていないファイルは退避しない)
git stash
# ブランチ作成と切り替え
git branch feature
git switch feature
# 退避したファイルを元に戻して、退避リストからも削除する
git stash pop stash@{0}
# feature ブランチでコミット
git add .
git commit -m "変更しました。"11. ファイルの削除
Git で管理しているファイルを削除する場合、エクスプローラなどでファイル削除するのではなく、git rm で削除する必要があります。
コマンド
git init
echo 'test' > test.txt
git add .
git commit -m "作成しました。"
# test.txt を削除してコミット
git rm test.txt
git add .
git commit -m "削除しました。"12. ステージングエリアについて
ファイルの作成・変更した場合は、git add でステージングエリアに追加してからコミットします。
そのため、ステージングエリアには、コミットすべきファイルだけがあるように思えますが、
実際には、1度追加されたファイルは、ファイルが削除されない限りに、ずっと保持されています。
ステージングエリアのファイル一覧は次のコマンドで確認できます。
コミットの前後で確認しても、同じ内容が表示されます。コミットしてもクリアされません。
それでは、ファイル変更後に git add をした場合、何が行われるかと言うと、
ステージングエリアで保持しているファイルのハッシュ値が更新されます。
そしてコミット時は、コミット済みのファイルのハッシュ値と、ステージングエリアのハッシュ値を比較して、異なる場合に git add されたと判断して、リポジトリに登録します。
そのため、ステージングエリアには、コミットすべきファイルだけがあるように思えますが、
実際には、1度追加されたファイルは、ファイルが削除されない限りに、ずっと保持されています。
ステージングエリアのファイル一覧は次のコマンドで確認できます。
コマンド
git ls-files --stage
実行結果
100644 3cacc0b93c9c9c03a72da624ca28a09ba5c1336f 0 test.txt
100644 d8263ee9860594d2806b0dfd1bfd17528b0ba2a4 0 test2.txt
ファイルのハッシュ値とファイル名が確認できます。コミットの前後で確認しても、同じ内容が表示されます。コミットしてもクリアされません。
それでは、ファイル変更後に git add をした場合、何が行われるかと言うと、
ステージングエリアで保持しているファイルのハッシュ値が更新されます。
そしてコミット時は、コミット済みのファイルのハッシュ値と、ステージングエリアのハッシュ値を比較して、異なる場合に git add されたと判断して、リポジトリに登録します。
次の記事 >
Git と GitHub との連携

