これまで私たちは理想的なシナリオを扱ってきました：コードを書き、コミットし、Pull Requestを作る。でも現実にはよく何かがうまくいかない：コードにミスをしてしまったり、コミットメッセージを間違えたり、単に方向性を間違えたと気づいたりします。この講義では、もっとも頻繁に起きる問題の解決方法を見ていきます。
1. Rollback — コミット前の変更を取り消す
シナリオ: ファイルを変更したけど、やっぱりその変更は全部間違っていて、最後にコミットされた状態に素早く戻したい場合。
機能Rollbackを使います：
Commitタブを開きます。- 一覧から戻したい変更されたファイルを見つけます。
- そのファイルを右クリックして
Rollbackを選択します。
IDEが変更が失われると警告します。承認すれば、ファイルは瞬時にGitに最後に保存されていたバージョンに戻ります。これはローカルの変更を取り消す最も簡単で安全な方法です。
2. Reset — ローカルコミットを削除する
シナリオ: 1つか複数のコミットをしてしまったが、まだpushしていない。これらのコミットが間違いだと分かり、まるでなかったかのように完全に消したい場合。
Reset機能を使います：
Git -> Logタブを開いてコミット履歴を確認します。- 自分が戻りたい最後の「良い」コミット（間違ったコミットの前のもの）を見つけます。
- そのコミットを右クリックして
Reset Current Branch to Here...を選びます。
開いたウィンドウでリセットモードを選ぶよう促されます。最も過激なのがHardです。
注意！ モードHardは、選択したコミット以降のすべてのコミットと、それらのコミットに含まれていたコードの変更を取り返しのつかない形で削除します。慎重に使い、まだ誰も見ていない（つまりGitHubに送っていない）コミットに対してのみ使ってください。
3. Pushした後はどうする？
シナリオ: pushした後に初めてエラーに気づいた場合。
コミットがリモートサーバーに到達すると、それはプロジェクトの共有履歴の一部になります。この履歴を書き換えようとすると、同僚に大きな問題を引き起こす可能性があります。彼らがすでにあなたの変更を取得して、その上で作業を始めていると想像してください。
正しくて安全な解決法：
単にエラーを修正する新しいコミットを作って、それを送信してください。これはまったく普通のやり方です。こうすることで履歴は誠実で分かりやすいまま保たれます。
4. 過去を覗く：高度なログの使い方
私たちはすでにGit -> Logタブに慣れていますが、これは単なるコミットの一覧ではなく、調査のための強力なツールです。
- コミットハッシュ (Commit Hash): ログに文字と数字の列（例：
a1b2c3d）があるのに気づいたでしょうか。このハッシュはユニークで、プロジェクトの任意の時点を正確に参照できます。手動で使う機会は少ないかもしれませんが、これが各スナップショットの一意の識別子であることを知っておくことは重要です。![]()
- 履歴をブランチ、作者、日付、あるいはコミットメッセージの単語でフィルタできます。これは誰がいつ特定の機能部分に取り組んだかを素早く見つけるのに役立ちます。
- 特定のコード行が追加または削除されたコミットを見つけたいですか？
Logウィンドウには検索フィールドがあり、メッセージだけでなく変更内容自体も検索します。 - コードエディタの行番号部分を右クリックして
Annotate with Git Blameを選んでください。IDEは各行の横に、誰がどのコミットで最後に変更したかを表示します。なぜそのコードがそう書かれているのかを理解するのに非常に役立ちます。
5. 危険地帯：Force Push
さて、送信済みコミットを書き換えるのは良くないと確認しました。でも、たとえばResetでローカル履歴を変えた結果、ローカルとサーバーの履歴が食い違ってしまったらどうしますか？通常のpushを試みると、Gitは履歴の上書きを防ぐためにエラーを出します。
そういう場合にはオプションがあります — force push（強制送信）。このコマンドはサーバーに対して「あなたが持っているものは忘れて。私のローカル履歴が真実だ。あなたの履歴を私の履歴で置き換えてくれ」と言うものです。
注意！ チームプロジェクトでforce pushを使うのは99%のケースで壊滅的です。すでに同僚がダウンロードして作業しているコミットを取り返しのつかない形で削除する可能性があります。図書館の共有本からページを引き裂いて、自分のページを貼るようなものです。
絶対に使ってはいけないとき：
- 共有ブランチ：
main、develop、master。絶対にダメ。 - 自分以外の誰かが使っているブランチ。
唯一許されるシナリオ：
あなたが誰にも見られていない自分専用のfeatureブランチで作業している場合。いくつか「汚い」コミットをしてサーバーに送ってしまい、その後Resetで履歴をきれいにしたいと判断した場合。このときはforce pushしてサーバー上の自分のブランチを更新してからPull Requestを作るのは許容されます。
IDEではこのオプションは通常Pushボタンの奥に隠されています。開発者が誤操作を防ぐために意図的にそうしています。
100%自信がないなら、決してforce pushを使わないでください。修正の新しいコミットを作るほうが安全です。
6. プロジェクトの更新
新しいタスクを始める前に、常にmainブランチでUpdate Projectを押してください。これで将来の多くのマージコンフリクトを避けられ、最新のコードバージョンから作業を始めることが保証されます。
GO TO FULL VERSION