「git addって何のためにあるの」「pushしたらエラーが出た」——Gitを使い始めたころは、コマンドの意味と手順の順番が一致せずつまずきがちです。この記事では、リポジトリの作成からリモートとの同期、ブランチ操作まで、実際の作業順に沿って基本コマンドを整理します。

リポジトリを作る: init と clone

Gitでの管理を始める方法は2通りあります。

新規にプロジェクトを始める場合は、そのフォルダで初期化します。

git init

すでにGitHubなどにあるリポジトリを手元に持ってくる場合は、履歴ごと丸ごと複製します。

git clone https://github.com/ユーザー名/リポジトリ名.git

initは空のリポジトリを新しく作るコマンド、cloneは既存のリポジトリを（コミット履歴も含めて）まるごとコピーしてくるコマンドという違いがあります。ゼロから始めるならinit、誰かが作ったプロジェクトに参加するならcloneと覚えておけば迷いません。

変更を記録する: add と commit

ファイルを編集しただけでは、Gitはまだその変更を記録していません。記録には2段階の操作が必要です。

まず、変更内容を「ステージングエリア」という一時領域に置きます。

git add ファイル名
git add .

ファイル名を指定すればそのファイルだけ、ドット(.)を指定すれば変更のあったファイルすべてがステージングされます。

次に、ステージングした内容を実際の記録（コミット）として確定させます。

git commit -m "コミットメッセージ"

addとcommitを分ける理由は、複数ファイルを編集した中から「今回の記録に含めるものだけ」を選んで一つのまとまった変更として残せるようにするためです。関係のない修正を一緒くたにコミットせずに済みます。

状態を確認する: status と log

作業中、今どういう状態にあるかをいつでも確認できます。

git status

statusは、ステージング済みのファイル・変更したがまだステージングしていないファイル・Gitが認識していない新規ファイルを一覧表示します。addやcommitの前に確認する習慣をつけると、意図しないファイルを記録してしまうミスを防げます。

過去のコミット履歴を見るには次を使います。

git log
git log --oneline

—oneline をつけると各コミットが1行に短縮され、全体の流れを見渡しやすくなります。

リモートと同期する: push と pull

commitはあくまで手元のリポジトリへの記録です。GitHubなどのリモートリポジトリに反映するには、別途送信の操作が必要です。

git push origin ブランチ名

逆に、リモート側で加えられた変更（他の人の作業など）を手元に取り込むには次を使います。

git pull origin ブランチ名

pullは内部的に「リモートの最新情報を取得する（fetch）」と「それを手元のブランチに合流させる（merge）」を一度に行うコマンドです。

毎回origin ブランチ名と書くのが面倒な場合は、最初の一度だけ追跡ブランチ（upstream）を設定しておくと、以降はgit push・git pullだけで済むようになります。

git push -u origin ブランチ名

-u（—set-upstreamの短縮形）をつけて一度pushすると、そのローカルブランチとリモートブランチの対応が記録され、次回以降はブランチ名の指定が不要になります。

ブランチを操作する: branch・checkout・merge

ブランチは、本流（多くの場合main）に影響を与えずに作業できる並行した作業スペースです。

新しいブランチを作って切り替えるには次を使います。

git checkout -b 新ブランチ名

git branch 新ブランチ名でブランチを作り、git checkout 新ブランチ名で切り替える、という2段階の操作を-bオプションで1コマンドにまとめたものです。

作業が終わったブランチの内容を、別のブランチ（多くはmain）に取り込むには次を使います。

git checkout main
git merge 作業ブランチ名

まず取り込み先のブランチに切り替えてから、merge対象のブランチ名を指定する順番に注意します。

よくあるつまずき

CRLFとLFの警告

WindowsとLinux/macOSでは改行コードの扱いが異なり(Windowsは CRLF、Linux/macOSは LF)、コミット時に警告が出ることがあります。Gitの core.autocrlf 設定で自動変換を制御でき、公式ドキュメントではWindows環境ではtrueに、Linux/macOS環境ではinputに設定することが推奨されています。trueはチェックアウト時にLFをCRLFへ、コミット時にCRLFをLFへ変換し、inputはコミット時の変換のみ行いチェックアウトには手を加えません。チーム開発では.gitattributesファイルで改行コードのルールを統一しておくと、環境差による警告や差分を防げます。

detached HEAD状態

git checkout コミットハッシュ のように、ブランチ名ではなく特定のコミットを直接指定してチェックアウトすると、「detached HEAD」という状態になります。この状態でコミットを作ると、どのブランチにも属さない孤立したコミットになり、別のブランチへ切り替えた時点で参照を失いやすくなります。過去のコミット内容を確認したいだけなら問題ありませんが、そこから作業を続ける場合は、その場で新しいブランチを作って（git checkout -b 新ブランチ名）から進めるのが安全です。

マージコンフリクトの基本対処

同じファイルの同じ箇所を別々のブランチで変更していると、mergeやpullの際にコンフリクト（衝突）が発生します。該当ファイルには次のようなマークが挿入されます。

<<<<<<< HEAD
（現在のブランチの内容）
=======
（取り込もうとしている内容）
>>>>>>> ブランチ名

このマーク部分を手で編集し、残したい内容だけを書いて<<<<<<<・=======・>>>>>>>の行を削除します。修正が終わったら通常通りgit addで保存し、git commitでコンフリクト解消のコミットを作って完了です。

.gitignoreの基本

ビルド成果物や環境依存の設定ファイル、秘密情報などをGitの管理対象から外したい場合は、リポジトリ直下に .gitignore というファイルを作り、除外したいファイルやフォルダのパターンを1行ずつ書きます。

node_modules/
.env
*.log
dist/

フォルダ名の末尾にスラッシュ(/)をつけるとそのフォルダごと除外、*のようなワイルドカードで拡張子単位の除外もできます。すでにGitの管理下に入ってしまっているファイルは、.gitignoreに追記しただけでは除外されないため、git rm —cached ファイル名 で管理対象から外してからコミットする必要があります。

まとめ

Gitの基本操作は、init/cloneでリポジトリを用意し、add/commitで変更を記録し、push/pullでリモートと同期し、branch/checkout/mergeで作業を分岐・統合する、という流れに沿っています。エラーメッセージが出たときも、今どの段階の操作なのかを意識すれば原因を切り分けやすくなります。

---

本記事のcore.autocrlf設定に関する記述は、Git公式ドキュメント（Customizing Git - Git Configuration）およびGitHub公式ドキュメント（Configuring Git to handle line endings）を基に確認しています。