git init
作業ディレクトリに.gitフォルダを作成し、そのフォルダ以下をGitで管理できるようにします。
- 現在のディレクトリに .git フォルダを作成し、Gitのバージョン管理を開始
- 初回のプロジェクトで「Git管理を開始したい」ときに使用
git clone
既存のリモートリポジトリをローカルにコピーします。
例
git clone https://github.com/user/repo.git
-
originという名前でリモートが設定される
git add
変更されたファイルを「ステージング領域」に追加します。
例
（ すべての変更を追加 ）
git add .
（ 特定ファイルだけ追加 ）
git add ファイル名
-
.（ドット）は「すべての変更されたファイル」をステージング（準備）する意味- ステージングとは「これらのファイルを次のコミットに含めるよ」とGitに伝えること
git commit
ステージングされた変更をコミット（履歴として記録）します。
例
（ コミットメッセージをその場で書く（message の略） ）
git commit -m "コミットする"
（ 直前のコミット内容やメッセージを修正する ）
git commit --amend -m "修正したコミットメッセージ"
-
-mオプションは “message” の略- コミットには必ずメッセージが必要で、変更内容の概要を記述
-
--amendオプションは以下のようなことが可能になります- コミットメッセージの変更
- ステージし忘れたファイルの追加・修正
- テスト的なコミットをきれいにまとめ直す
git status
作業ディレクトリの現在の状態（変更・ステージングの有無など）を確認します。
- どのファイルが変更されたか、ステージされているか、まだコミットされていないかを確認
- よくある使い方の流れ：
1.ファイルを編集する
2.git statusで変更を確認する
3.git add→git commitと進める
git diff
ワーキングツリー（作業ディレクトリ）の変更内容を表示します。
- ステージングされていない変更の差分（diff）を表示
- どこを編集したのかを確認したいときに便利
例
（ 作業ツリーとステージの差分を表示（未ステージ） ）
git diff
（ ステージングされた変更と最後のコミットの差分表示 ）
git diff --staged
（ 現在の作業状態と最新のコミットとの差分表示 ）
git diff HEAD
-
--stagedは、ステージされた内容が「このままコミットして大丈夫か」を確認するときに使う -
HEADは、ステージングされていようがいまいが、作業中の変更すべてをまとめて比較できる
git log
過去のコミット履歴を表示
例
（ 過去のコミット履歴を表示 ）
git log
（ 各コミットを1行で表示（ハッシュ＋メッセージ） ）
git log --oneline
（ ブランチの流れ（マージなど）を視覚的に表示 ）
git log --graph
（ 各コミットでの変更差分も表示 ）
git log -p
（ 指定した作者のコミットのみ表示 ）
git log --author="名前"
（ 過去2日間のコミットだけ表示（自然言語OK） ）
git log --since="2.days"
- チーム開発中に「誰がいつ何をしたか」を追跡
- 直前のコミットを確認し、
revertやresetで戻したい
git remote add origin
ローカルリポジトリにリモートリポジトリを登録します。
- GitHubで新しくリポジトリを作成したあと、ローカルとつなぐために使う
- 通常は
git pushを使う前に一度だけ設定
例
git remote add origin https://github.com/ユーザー名/リポジトリ名.git
-
remote addは、リモートリポジトリを追加するコマンド -
originは、リモートリポジトリに付ける名前（慣習的に “origin” を使う） - [URL] は、リモートリポジトリのURL（GitHub等で表示されるHTTPS/SSH URL）
git push
ローカルリポジトリの変更をリモートリポジトリに反映（プッシュ）します。
例
（ 初回の push（ローカルとリモートを関連付け） ）
git push -u origin main
（ 2回目以降の push（-u 省略可） ）
git push
（ develop ブランチをリモートに push ）
git push origin develop
-
-uは、初回push時に使用することで、ローカルのブランチとリモートのブランチ（origin/main など）を「ひも付け」する- この設定をすると、次回以降は
git pushだけで OK になる
- この設定をすると、次回以降は
-
originは、リモートリポジトリの名前（通常は origin） -
mainやdevelopは、プッシュしたいローカルのブランチ名（例：main, develop など）
これで GitHub 上のリポジトリにコードがアップロードされ、他の人と共有できるようになります。
git pull
リモートリポジトリの最新の変更を取得して、ローカルに自動でマージします。
例
（ トラッキング済みのリモートブランチから取得＋マージ（origin/main など） ）
git pull
（ 明示的に origin/main を指定して取得＋マージ ）
git pull origin main
（ マージではなくリベースで取り込む（履歴をきれいにしたいとき） ）
git pull --rebase
-
originは、リモートリポジトリの名前（通常は origin） -
mainは、リモートブランチ名（例：main, develop）
このコマンドは、git fetch（リモートから最新情報を取得）とgit merge（取得した変更をローカルブランチに統合）の処理を一度に行います。
チーム開発中に他の人が push した最新の変更を取り込むときにしようします。
もしコンフリクト（競合）が発生した場合は、手動で解決 → add → commit が必要になります。
git branch
ブランチを確認・作成・削除するためのコマンドです。
例
（ ブランチ一覧を表示 ）
git branch
（ 新しいブランチを作成（切り替えはされない） ）
git branch ブランチ名
（ ブランチを削除 ）
git branch -d ブランチ名
（ 強制的に削除 ）
git branch -D ブランチ名
-
-dは「delete（削除）」の略- すでに他のブランチへマージされたブランチだけ削除できます
- 未マージのブランチはエラーになります（誤削除防止のため）
-
-Dは「強制削除（force delete）」を意味します- -d の厳格チェックを無視して削除します
- 誤って削除すると復元が面倒なので注意が必要です
git switch
ブランチを切り替える、または新しく作って切り替えるためのコマンドです（Git 2.23 以降推奨）。
例
（ 既存のブランチに切り替え ）
git switch ブランチ名
（ 新しくブランチを作って、そのまま切り替え ）
git switch -c ブランチ名
-
-cは「create（作成）」の略- すでに存在するブランチ名を指定するとエラーになります
git checkout に比べて安全でわかりやすいため、初学者にはこちらをおすすめします。
git checkout
もともとブランチの切り替えや、特定のファイル・コミットの復元に使われていた多機能コマンドです。
例
（ 指定したブランチに切り替え（古い方法） ）
git checkout ブランチ名
（ 新しいブランチを作成＆切り替え（switch -c と同じ） ）
git checkout -b ブランチ名
（ ファイルの変更を取り消す（ステージ前の状態に戻す） ）
git checkout -- ファイル名
（ 過去のコミット状態に一時的に切り替える（閲覧目的） ）
git checkout コミットID
-
-bは「branch（ブランチ）」の略- 現在のブランチを元に、新しいブランチを作ってすぐに移動します
-
switch -cと同じ動作だが、旧バージョンの Git でも使えます
-
--（ダブルハイフン）は「ブランチ名との区切り」を意味します- これがないと Git は ファイル をブランチ名と誤認する可能性があります
- このコマンドは「最新版のファイルを取得して、ローカル変更を破棄」します
- ファイルを復元する目的なら
git restore ファイル名が推奨されます（Git 2.23～）
Git 2.23 以降では、ブランチ操作は git switch、ファイル復元は git restore を使うように推奨されています。
git merge
別のブランチで行った変更を、現在のブランチに統合（マージ）します。
例
（ 指定したブランチを現在のブランチにマージする ）
git merge ブランチ名
（ 必ずマージコミットを作成する（履歴を明示的に残したいとき） ）
git merge --no-ff ブランチ名
-
--no-ffは、「Fast-forward」にならず、マージコミットを必ず作る（履歴を明示）
マージは「複数人・複数ブランチ」での開発に欠かせない重要な操作です。
複雑な開発では「Pull Request（PR）」を通じてマージすることが一般的です（GitHub など）。
| 状況 | 結果 |
|---|---|
| 変更点が重複しない | 自動でマージされる（fast-forward or 通常マージ） |
| 同じ箇所を両方のブランチが変更している | コンフリクト（衝突）が発生し、手動で解決が必要 |
コンフリクト発生時は、対象ファイルを編集 → 解決 → git add → git commit を行ってください。
git restore
作業ツリーの変更を取り消して、以前の状態に戻すコマンドです（Git 2.23 以降で追加）。
例
（ ファイルの変更を元に戻す ）
git restore ファイル名
（ すべてのファイルを元に戻す ）
git restore .
（ ステージングした変更（git add）を取り消す ）
git restore --staged
-
.（ドット）は、カレントディレクトリ以下すべてを対象にする -
--stagedは、ステージングから外し、作業ツリーには変更を残す
git restore を使うと、変更は完全に失われます。
重要な変更を失わないよう、実行前に git diff などで確認するのが安心です。
git reset
コミットやステージング（git add）を取り消すためのコマンドです。
例
（ 最後のコミットを取り消したい（変更は残したい） ）
git reset --soft HEAD^
( ステージングだけを取り消したい（デフォルト動作） )
git reset --mixed HEAD
( すべての変更を完全に取り消す（注意！） )
git reset --hard HEAD
-
HEAD^は「直前のコミット」を指します -
--soft HEAD^は、コミットは取り消されるが、変更内容はステージされたまま残ります- 修正して再コミットする場合などに便利
-
--mixed HEADは、git add でステージした変更を「作業ツリーの状態に戻す」- ファイル自体は元に戻らず、編集状態はそのまま
-
--hard HEADは、コミットもステージも作業ツリーの変更もすべて破棄され、最後のコミットの状態に戻ります- 取り消し不可なので慎重に！（変更が完全に消えます）
| 書き方 | 意味 |
|---|---|
| HEAD | 現在の最新コミット |
| HEAD^ | 1つ前のコミット |
| HEAD^^ | 2つ前のコミット |
| HEAD~3 | 3つ前のコミット |
Views: 0
