0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ちょっとわかった!Git

Last updated at Posted at 2025-07-18

はじめに

Git に関して学習したことをまとます。

Git 初期設定

git アップデート

ターミナル
git update-git-for-windows
git --version

git 設定いろいろ

ターミナル
# email 設定
git config --global user.email "email@email.com"
# Git で使用するデフォルトのテキストエディタを Visual Studio Code に設定
git config --global core.editor "code --wait"
# 一覧
git config --global -e

# Git 設定例
[user]
	email = email@email.com
	name = name

[init]
	default = branch
	defaultBranch = main

[diff]
	tool = vscode
[difftool "vscode"]
    cmd = code --wait --diff $LOCAL $REMOTE

[core]
	autocrlf = input
	editor = code --wait

[grep]
	lineNumber = true

↓を書き込んでターミナルを再起動すると、ターミナルにブランチ名が表示される。

.zshrc
autoload -Uz vcs_info
precmd() { vcs_info }
setopt prompt_subst
PROMPT='%n@%m %1~ ${vcs_info_msg_0_} %# '
zstyle ':vcs_info:git:*' formats '(%b)'

# XXX@XXXnoMacBook-Pro react-fastapi-postgres-template (main) %

Git 基本理解

0. git 管理なしの状態
↓ git init あるいは git clone [GitHubのURL]
1. ローカル環境
↓ git add .
2. ステージング環境
↓ git commit -m "<メッセージ>"
3. コミット環境
↓ git push origin <ブランチ名>
4. リモート環境
↓ git pull origin <ブランチ名>
1. ローカル環境

git init
.git フォルダが作成され git 管理が始まる。.git フォルダを削除すると git 管理をリセットできる。
git clone <GitHubのURL>
GitHub のリポジトリをローカルにクローンしてくる。リポジトリと一緒に git 管理状態もクローンしてくる。
git add .
ローカル環境からステージング環境に移動(コミット待ち状態になる)。. (ドット) の代わりにファイル名を指定して add もできる。
git commit -m "<メッセージ>"
ステージング環境からコミット環境に移動(コミット完了状態になる)。
git push origin <ブランチ名>
コミット環境からリモート環境に移動(GitHub にローカルの変更が反映される)。
git pull origin <ブランチ名>
リモート環境の変更をローカルに反映(GitHub の変更がローカルに反映される)。

commit に関して
未 commit 状態でブランチを移動はできない。移動先ブランチが移動元の変更内容で上書きされてしまうことがある。

push / pull に関して
ローカルのブランチ名とリモートのブランチ名が一致していることを確認する。ローカルのブランチAからリモートのブランチBに push などはNG。

Git よく使うコマンド

git 状態確認系(オプションは無くてもいい)

ターミナル
# コミットしたかしていないか
git status -s
# コミット履歴
git log --all --decorate --oneline --graph
# コミット履歴+それ以外の更に詳しい履歴
git reflog
# git 管理中のファイル一覧
git ls-files
# そのコミット時に変更した部分
git show <コミットID>

ブランチ間系

  • ブランチの 作成 / 移動 / 削除
ターミナル
# 作成
git switch -c <ブランチ名>
# 移動
git switch <ブランチ名>
# ローカルのブランチを削除
git branch -d <ローカルのブランチ名>
# リモートのブランチを削除
git push origin --delete <リモートのブランチ名>
  • ブランチのpull
ターミナル
# リモートからブランチを取得
git fetch -a
# fetch せずにリモートのブランチを取得
git checkout -b <ローカルで新しく作成するブランチ名> <リモートのブランチ名>
  • ブランチのマージ
ターミナル
git merge -m "<メッセージ>" <ブランチ名>

# コンフリクトしてしまったら?
# コンフリクトしているファイルを訂正し、add と commit をする
git add <ファイル名>
git commit -m "<メッセージ>"

# コンフリクトしてしまって途中でやめたいときは
git merge --abort

マージに関して
ブランチ A の変更をブランチ B に融合できる。
例えばブランチ B にいるときは git merge -m "<メッセージ>" <ブランチA>で、ブランチ A の変更状態を B にも反映できる。

コンフリクトに関して
マージするとブランチ同士の変更が競合することもある。
コンフリクトが起きるのは、マージする2つのブランチがそれぞれ別々に同じファイルを編集して commit したとき。
たとえば main ブランチに example.txt があるとする。main から切った test ブランチが example.txt に「Good morning」と書いて commit。一方そのとき main では「Good evening」と書いて commit。
これでマージすると、git はどちらの状態が正しいのかわからずコンフリクトが起きる。

Git 時々使うコマンド

ターミナル
# rm 系

# ファイルをステージング環境からローカル環境に移動(未 add 状態にする)
git rm --cached <ファイル名>
# ファイルをステージングからもローカルからも消す
git rm <ファイル名>
ターミナル
# mv 系

# AからBに名前変更 & 変更を add
git mv <ファイル名A> <ファイル名B>
ターミナル
# restore 系

# 変更 / 削除をステージング環境からローカル環境に移動(未 add 状態にする)
git restore --staged .
# 変更 / 削除をステージングからもローカルからも消す
git restore .
ターミナル
# checkout 系

# 過去の特定のコミット時の様子を見に行く
git checkout <コミットID>
# 現在に戻る
git checkout <ブランチ名>
ターミナル
# stash 系

# 今やっている作業を一時退避
git stash
# メッセージ付き退避
git stash push -m "<メッセージ>"
# 退避中の作業一覧
git stash list
# 退避した作業を復元&削除
git stash pop stash@{<番号>}
# 退避した作業の復元
git stash apply stash@{<番号>}
# 退避した作業を削除
git stash drop stash@{<番号>}

stash に関して
「commit に関して」で書いたように、commit せずにブランチ移動はしない方がいい。そのため stash で作業をいったん退避してからブランチ移動をするようにする。戻ったときに作業を復元できる。

ターミナル
# diff 系 変更の差分を確認

# ローカル環境と直前コミットとの差分
git diff
# ステージング環境と直前コミットとの差分
git diff --staged
# コミット間の差分
git diff <コミットID>..<コミットID>
# ブランチ間の差分
git diff <ブランチ名>..<ブランチ名>

git fetch origin
# ローカルとリモートの差分
git diff HEAD..origin/master
# リモートとローカルの差分
git diff origin/master..HEAD

Git あまり使わないコマンド

ターミナル
# revert と cherry-pick

# 特定のコミットで加えた変更を消す
git revert <コミットID>
# 特定のコミットで加えた変更を取り入れる(revert の逆)
git cherry-pick (-n) <コミットID>
ターミナル
# reset 系

# 戻りたい場所のコミットIDを確認
git reflog
# そのコミット時の状態に戻る
git reset --hard <コミットID>

# オプションに関して
--soft: 指定の状態に戻り、そのとき編集中だったことは commit だけ行っていない状態になる
--mixed: 指定の状態に戻り、そのとき編集中だったことは add だけ行っていない状態になる
--hard: 指定の状態に戻り、そのとき編集中だったことは消える
ターミナル
# その他

# 文字列検索 VSCodeが使えない環境で活躍
git grep "<文字列>"
# 特定のコミット時のファイルで文字列検索
git grep "<文字列>" <コミットID>

# ファイルの更新履歴を確認
git blame <ファイル名>

Git よくわからないコマンド

ターミナル
# rebase 系
# 他のブランチのコミット記録を取り込む?(以下参考画像)
# でも main で rebase してはいけないとも聞くので、使わない方が無難そう

Screenshot (232).png

関連:Git よく使うファイル

ファイル名 内容
.gitignore git 管理しないファイルを指定する(.envなど)。
.git 消すと git 管理がリセットされてしまうので触らない。

.gitignore に関して
add されたことがないファイル(git 未管理)は .gitignore できる。add 済みファイル(git 管理中)は先に管理を外す。

.gitignore に関して2
gitignore generator でいろいろな言語やフレームワークの .gitignore サンプルが提供されている。

余談:自分が新しくリポジトリを作る場合の初回 push のやり方

画像に2つコードブロックがあり、ローカルで何も git 管理をしていない場合は上のコードブロックを、ローカルで git init 済みなら下のコードブロックを実行する。
Screenshot (233).png
2回目以降は git push origin <ブランチ名> で push できるのだが、初回は git push -u origin mainになっている。-u = --set-upstream らしい。

余談:プルリクの作り方

1.プルリク作成
Screenshot (237).png
2.そのブランチがどういう意図で作られて、どういう変更を加えたのか、他の人が読んでわかるように書く。(ブランチ名確認!)
Screenshot (235).png
3.変更にフィードバックをもらい、問題なければマージ。フィードバックで問題を見つけてもらった場合は、ローカルから訂正して push する。
Screenshot (236).png

余談:GitHubへの鍵登録

↓この公式記事がわかりやすすぎて、後輩に鍵登録方法を教えるときは大体これ準拠でやっています。

GitHubアカウントに新しいSSHキーを追加する

おわりに

学習を経て、少し自信を持って Git を使えるようになったと思います。
今後は GitHub Actions の勉強もしていきたい。

参考にさせていただいた記事

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?