たとえば、サーバーのWebルートで、いくつかのコミットをプッシュして本番環境にプルしたとします。そして、何かがうまくいかない。明らかに、ほとんどの場合、Webルート内のファイルを一時的に以前の状態に戻し、ローカルの開発場所に戻って、壊れているものを修正し、テストし、何かを壊したコミットの上にコミットして、これらをプッシュすることです。新しい修正はマスターブランチにコミットします。次に、本番Webルートに再度移動し、すべてを最新のコミットにプルして、すべてが修正され、正しく機能するようにします。そうすれば、誰もがマスターブランチをプルするだけで、コミットの失敗やgitheadのリセットなどのイライラすることを心配する必要がなくなります。
だから：それは合法で安全な方法ですか
本番Webルート、マスターブランチ
>git log --pretty=format:"%h %ad | %s [%an]" --date=short
0fu83bd Wed Mar 6 17:47:42 2013 | Merge branch 'sample' [developer1]
fd442f8 Wed Mar 6 17:47:10 2013 | Some updates [developer1]
ad84471 Wed Mar 6 17:25:12 2013 | Added something [developer2]
ファイルの状態を一時的に元に戻したいコミットを見つけます。たとえば、ad84471
>git checkout ad84471
>git branch
* (no branch)
master
開発、修正、コミット、[マージ]、マスターブランチのプッシュを行う場所に移動します。その間、本番ファイルはad84471状態になり、誰も変更しません。次に、本番Webルートに戻ります。
>git checkout master
>git pull
>git branch
* master
>git log --pretty=format:"%h %ad | %s [%an]" --date=short
7guffbd Wed Mar 6 17:47:42 2013 | Fixed 0fu83bd bugs [developer1] <---new commit
0fu83bd Wed Mar 6 17:47:42 2013 | Merge branch 'sample' [developer1]
fd442f8 Wed Mar 6 17:47:10 2013 | Some updates [developer1]
ad84471 Wed Mar 6 17:25:12 2013 | Added something [developer2]
これでマスターブランチに移動し、すべてが正常に機能します。誰もが最新の変更をプルするだけで、準備は完了です。
md5deepを使用してファイルをチェックし、すべてが（修正をプルする前に）元に戻した状態に戻ることを確認しました。
>md5deep -rel webroot > hashes_master_before_checkouting_ad84471
>git checkout ad84471
>git checkout master
>md5deep -rel webroot > hashes_master_after_checkouting_master_again
これらのハッシュ間の差分は、
webroot/.git/logs/HEAD
webroot/.git/index
変わった。
だから、何かをすばやく修正するのは良い方法のように思えますか、それとも私は間違っていますか？
免責事項：多くのプロジェクトでは、これが意図したワークフローに反していること、この方法はあまり良くないこと、また前に自動テストを行う必要があることを知っていますが、開発者が少ない小さなプロジェクトでは、それが不可能または実用的でないことがよくあります、したがって、この方法は、git resetまたはrevertを使用する場合と比較して、多くの時間を節約し、作業を簡素化できます。