これまでは理想的なシナリオを見てきました: コードを書き、コミットし、プルリクエストを作成する。しかし現実の開発では、物事が思い通りに進まないことがよくあります。コードにミスをしたり、誤ったメッセージでコミットしたり、単に方向性を誤ったと気づくこともあるでしょう。本講義では、よくある問題をどう解決するかを解説します。
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を選択します。各行の横に、最後に誰がどのコミットで変更したかが表示されます。コードがそのように書かれている理由を理解するのに非常に有用です。
5. 危険地帯: Force Push
送信済みのコミットを書き換えるのは悪い考えだと確認しました。では、Reset などでローカル履歴を変更してしまい、サーバー上の履歴と食い違っている場合はどうでしょうか？ 通常の push を実行しようとすると、Git は共有履歴の上書きを防ぐためエラーを返します。
そのような場合のために — force push（強制送信）というオプションがあります。このコマンドはサーバーにこう告げます: 「今あるものは忘れて。私のローカル履歴が唯一正しい。あなたの履歴を私のものに置き換えてください」。
警告! チーム開発では 99% のケースで force push の使用は 破滅的 です。すでに同僚が取得し、その上で作業しているコミットを取り返しのつかない形で削除してしまう可能性があります。これは、共有の図書館の本からページを破り取り、自分のページを貼り付けるのに等しい行為です。
絶対に force push を使ってはいけないとき:
- 共有ブランチ:
main、develop、master。決して。 - 自分以外の誰かが作業しているブランチすべて。
唯一許されるシナリオ:
自分専用のフィーチャーブランチで作業しており、まだ誰にも見られていない。いくつかの「汚い」コミットをサーバーへ送った後、Reset でそれらを「整え」たい。この場合は、プルリクエストを作成する前にサーバー上の自分のブランチを更新する目的で force push を行っても構いません。
IDE では通常、このオプションは Push ボタンの裏に隠されています。誤って押してしまわないよう、あえてそう設計されています。
自分の操作に 100% の確信が持てないなら、force push は決して使わないでください。修正を含む新しいコミットを作成する方が安全です。
6. プロジェクトの更新
新しいタスクに取りかかる前には、必ず main ブランチで Update Project を実行しましょう。これにより将来のマージコンフリクトの多くを避けられ、最新のコードから作業を開始できることが保証されます。
GO TO FULL VERSION