なぜgitは「変更履歴」を許可するのですか？
可能性のある複製：
プロジェクトのVCS履歴をいつ削除する必要がありますか？
私はsvnの使用経験があり、最近gitの学習を始めました。 gitには「履歴を書き換える」機能があることを知って、私はかなりショックを受けました。
私はsvnから来て、変更がコミットされるとコミット自体を「元に戻す」方法はないというソース管理の原則をsacrosanctとして受け入れました...以前のコミットで行われた変更ですが、過去に行われたコミットの状態をいつでも再現できます。
この「原則」を変更する理由は何ですか？これをOKにするgitの違いはありますか、それともgitの設計はsvnの「哲学」とは異なるソース管理の異なる「哲学」を反映していますか？
最も重要な理由はセキュリティです。クリアテキストのパスワードまたはその他の機密情報を含むファイルを誤ってチェックインしたとします。情報を削除して新しいバージョンをチェックインしても、履歴には表示されます。
また、履歴を「よりクリーン」にすることも時々役立ちます。たとえば、独自のリポジトリで作業している場合、何が機能するかを実験的に試すときに、複数の小さな変更をチェックインすることがあります。最終的に変更が機能するようになったら、それらの変更をすべて別のリポジトリにプッシュしたくない場合があります。つまり、それらを単一の変更にまとめることができます。プライベートサンドボックスで開発しているときに、変更内容の非常に詳細な履歴と、以前のバージョンに戻る機能が必要になる場合があります。最終的に問題を解決し、修正が、たとえば一目でわかる1行の変更であることが判明したら、その履歴を別の履歴にプッシュallする必要はありません。 repo（おそらく、プロジェクトの中心的なリポジトリとして機能するリポジトリ）。
Gitはポリシーをコードに固定しないという原則に従います。そのため、高度に技術的なユーザーの手にある柔軟性は、ミスを防ぐことよりも重要です。コミットとそれに続くすべてのコミットのSHA-1ハッシュが変更されるため、人々が気付かない限り、gitで履歴を書き換えることは不可能です。これは実際にはsvnの改良版であり、履歴を簡単に書き換えることはできませんが、可能になり、いつ行うかを検出することが難しくなります。
CVCSとDVCSには、略語の最初の文字だけでなく、コアの原則にも大きな違いがあります。CVCSの場合、公開されたコミットは共通の共有履歴で、コミットされますが- プッシュされない DVCSでコミット-ローカルの個人履歴、これは作者以外には影響しません。
後者の場合、歴史の変化は一人の問題だけであり、*自分の混乱の混乱と無秩序な働き方に責任があります。
そして、ついに、それはちょうどanother styleであり、生きる権利を持つスタイルでもあります。 「実践は真実の基準である」ので、書き直しが破棄されなければ、ツールでそれを使用することを妨げるものは何もないので、簡単に行うことができます。