Git Revert vs Reset：それぞれの使い分け
git revertとgit resetの重要な違いを理解します。共有ブランチかプライベートブランチかに基づいて、各コマンドをいつ使用するかを学びます。
Undoing Changes
詳細な説明
Git Revert vs Git Reset
git revertとgit resetはどちらも変更を元に戻しますが、根本的に異なる方法で動作し、異なる状況で適切です。
git reset：履歴の書き換え
git resetはブランチポインタを後方に移動し、ブランチ履歴からコミットを実質的に消去します。
# 最後の2つのコミットを取り消し、変更をステージ状態で保持
git reset --soft HEAD~2
# 最後のコミットを取り消し、すべてを破棄
git reset --hard HEAD~1
resetを使う場面：
- プッシュされていないプライベート/ローカルブランチ
- プッシュ前にコミットを整理したい場合
- インタラクティブリベースのワークフロー
危険： 共有ブランチにプッシュされたコミットをリセットすると、他の開発者の履歴と分岐し、マージコンフリクトや混乱を引き起こします。
git revert：履歴の保存
git revertは指定されたコミットの逆である新しいコミットを作成します。元のコミットは履歴に残ります。
# 特定のコミットをリバート
git revert abc1234
# 最後のコミットをリバート
git revert HEAD
# 自動コミットなしでリバート
git revert --no-commit abc1234
revertを使う場面：
- 共有/パブリックブランチ（main、develop）
- 監査のために履歴を保存する必要がある場合
- 他の開発者が既にコミットをプルしている場合
- 本番ホットフィックスのシナリオ
判断フローチャート
- コミットは共有ブランチにプッシュ済み？ ->
git revertを使用 - まだプッシュしていないプライベート/フィーチャーブランチ？ ->
git resetを使用 - 監査履歴を保存する必要がある？ ->
git revertを使用 - ローカルの乱雑なコミットを整理したい？ ->
git resetを使用
ユースケース
revert vs resetの理解は、チームベースの開発において重要です。共有ブランチでresetを使用することは、チーム全体の問題を引き起こす最も一般的なGitの間違いの一つです。この知識は、ソロプロジェクトから協調的なワークフローに移行する開発者、およびデプロイされたコミットを安全に元に戻す必要がある本番インシデントの処理に特に重要です。