困ってた自分に届けたい話
「あのとき、コマンド知っていれば…！」
初めてチーム開発に参加したとき、GitHubの操作に自信がなくて、GUIでぽちぽちと安全そうなボタンを押すばかり。正直、黒い画面（CLI）ってプロっぽくてかっこいいけど、自分にはまだ早いと思ってました。
でも、GUIのツールがアップデートされたり、チームごとに使うツールが違ったりすると、
「え、どこ押せばよかったっけ？」と、毎回迷子に。
そのうち、
- 同じブランチ名で強引にプッシュしてコンフリクトの嵐
- コミットメッセージがバラバラで履歴がぐちゃぐちゃ
- リモートの変更を取り込まないまま作業を進めて大混乱
という、地味だけど痛いトラブルを何度も経験。
「コマンドで操作できていれば、もっと早く正しく対応できたのに…！」と何度も後悔しました。
この記事は、同じように困っていた方への備忘録兼シェアとして書いています。
リポジトリの初期化・クローン
新しく作るとき（自分でゼロから開発を始めるとき）
git init自分だけのポートフォリオサイトを作るときや、チームにまだ共有しない段階の個人開発を始めるときに、すでに作成したフォルダの中でこのコマンドを打つことで、そのフォルダが「Gitで履歴管理できる状態」になります。その後、GitHubに新しく作ったリモートリポジトリと紐づけるためには、次のようにします。
git remote add origin https://github.com/ユーザー名/リポジトリ名.gitこれで、ローカルとGitHubの接続が完了します。
他の人のリポジトリやチームのリポジトリを使いたいとき
git clone https://github.com/チーム/リポジトリ名.gitすでにあるプロジェクトを自分のPCに持ってきたいときに使います。GitHubの「Code」ボタンからURLをコピーして、ターミナルでこのコマンドを実行すると、フォルダごと全部ダウンロードされます。履歴も含まれるので、過去の変更もすべて確認できます。
コミットと履歴管理
ファイルを追加・変更したら履歴に残すとき
git add .
git commit -m "ヘッダーのデザインを調整"コード修正したあと、そのまま次の作業に進むのではなく、まず変更を一つの「区切り」として記録しておきたいときに使います。git add . は、全ての変更されたファイルを「記録準備OK」の状態にするコマンドです。
その後、git commit -m "..." でメッセージをつけて保存します。
ここでのメッセージは「何を」「なぜ」変更したのかをチームがわかるように簡潔に書きましょう。
直前のコミットを修正したいとき
git commit --amend「コミットしたあとにファイルの入れ忘れに気づいた」「メッセージに誤字があった」「やっぱりちょっと修正したい」——そんなときに使えるのが git commit --amend です。
このコマンドを実行すると、直前のコミットを上書きする形で修正できます。たとえば、ファイルを追加し忘れていたなら、そのファイルを git add でステージングしてから git commit --amend を実行すれば、1つのまとまったコミットにすることができます。
なお、すでにGitHubにpushしているコミットをamendすると履歴が変わるため注意が必要です（その場合は --force 付きで再pushが必要になります）。
ローカル作業中に「コミットやり直したい」と思ったら、まず git commit --amend を思い出してみてください
過去の履歴をパッと確認したいとき
git log --oneline --graph --decorate誰がいつどんな変更をしたかを見たいときに使います。
長い履歴をだらだらと読むのではなく、1行ずつコンパクトに見られるので視認性がとても良いです。--graph をつけることで、どのブランチがどこから分かれて、どこで合流したかもわかりやすくなります。
ブランチ操作
作業用の新しいブランチを作って、すぐに移動したいとき
git switch -c 新しいブランチ名最近のGitでは、ブランチの切り替えや作成は git checkout よりも git switch を使うのが主流になっています。たとえば新しいブランチを作ってすぐにそのブランチに移動したいときには、git switch -c feature/新しいブランチ名 のように書くと、一発でローカルブランチ作成・切り替えが完了します。
すでに作られているブランチに移動したいときは、git switch ブランチ名 だけでOKです。
今のブランチを確認したいとき・他のブランチを見たいとき
git branch今までに作成されたローカルブランチが一覧で表示されます。今自分がいるブランチには * がついています。作業の前に「今どこにいるか」を確認する習慣をつけるとミスが減ります。
異なるローカルブランチで作業していたことがあり、大変な目に何度もあっている主です。この習慣は大切です… !
作業が終わったブランチを削除したいとき
git branch -d feature/完了したブランチ不要になったブランチはこまめに消すことで、ローカルがスッキリします。
まだマージしていないのに間違って消そうとすると警告が出ますが、どうしても削除したい場合は -D を使って強制削除もできます。
リモートリポジトリ操作
自分の作業をGitHubにアップしたいとき
git push origin feature/新機能名作業した内容をチームに共有したいときには、このコマンドでGitHubにアップします。origin はGitHub側のリポジトリ名を意味し、その後に続くのが自分のブランチ名です。もし初めてのプッシュで「上手くリンクできていない」場合は、次のように書くことで自動的に紐づけされます。
git push -u origin feature/新機能名こうしておけば、次回以降は git push だけでOKになります。
他の人の変更を自分の作業に反映させたいとき
git pull --rebaseGitHub上で別の人が更新していた場合、自分のローカルを最新にしてから作業を再開したいときに使います。--rebase をつけることで、マージコミットを発生させずに履歴をキレイな状態に保てます。
マージ・コンフリクト解消
他のブランチの内容を今のブランチに統合したいとき
git merge ブランチ名たとえば、現在作業している feature/login-form ブランチに、チームがまとめているメインの開発ブランチ（例：develop や main）の最新変更を取り込みたいときに使います。
この「ブランチ名」の部分には、「取り込みたい変更がある側のブランチ名」を指定します。よくある例としては develop や main ですが、会社やプロジェクトによっては staging や release など別の名前を使っていることもあります。
コンフリクトが起きたとき
ファイルの中に <<<<<<< や ======= が現れたら、それがコンフリクトです。
自分の変更と他の人の変更がぶつかってしまった状態なので、エディタで手動で「どちらを残すか」「どう融合するか」を判断します。修正したら、次のコマンドでコンフリクトが解消されたことをGitに伝えます。
git add コンフリクト解消済みファイル
git commitトラブルシュート
直前のコミットとの差分を見たいとき
git diff HEAD~1 HEAD「この前のコミットから何を変えたっけ？」という場面で使います。ファイルを開かなくても、ターミナル上で変更点が確認できます。
昔のコミットに戻したいとき（でも履歴は壊したくない）
git revert <コミットID>「やっぱりこの機能、いらなかったな…」というときに使います。revert を使えば、「そのコミットを取り消すための新しいコミット」を作ってくれるので、履歴はきれいなまま残ります。履歴を壊す reset より安全です。
作業中の変更を一時的に退避したいとき
git stash今まさにファイルを編集している途中に「緊急で別ブランチに切り替えて修正お願い！」という指示が来たとします。でもまだコミットもしていないし、今の作業内容は残しておきたい…。そんなときに便利なのがこの git stash コマンドです。
これを実行すると、作業中の変更内容を一時的に「しまっておく」ことができます。ブランチを切り替えたあと、元に戻ってから git stash pop を使えば、さっきまでの変更内容がちゃんと復元されます。
おつかれさまでした！
コメント