以前は、Mercurial のコミットに戻って編集し、きれいな履歴を作成しようとしていました。関係のない 2 つのことを 1 つのコミットに入れたり、複数のコミットを行って 1 つのコミットとして理解した方がよいかもしれませんが、最終的には時間の無駄のように思え、履歴が完全ではないという小さな恥ずかしさを乗り越えることができました。
あなたはまだこれをしますか？なぜそれはあなたにとって価値があるのですか、なぜもうやらないのですか、これをやったことがありますか、または始めようと考えていますか?
もし私が Linux カーネルに貢献していたら、Linus が私のパッチを拒否するので、これは明らかに私の時間の価値があるでしょう。私のプロジェクトには通常、数人の開発者しかいません。
努力する価値はありません。
「ヒント」がきれいである限り、歴史を醜くして、作品がどのように生まれたかではなく、作品がどのように生まれたかを正確に反映する方が良い.
歴史を掘り下げているとき、半分の時間、「これはかつてどのように見えたのですか?」と尋ねています。しかし、残りの半分の時間は、「なぜこれがこのようになったのか」と尋ねており、開発者が失敗した道をたどろうとしたという事実を消したいとしても、開発者の失敗した試みを見たいと思っています。うまくいきません。
私は改訂履歴をきれいにする努力をしています。私のワークフローは、小さくても意味のある編集を行い、コミットし、一連の大きな変更が行われるまで繰り返します。次に、戻ってコミットを並べ替え/グループ化し、機能的にアトミックなコミットにし、それらの改訂されたコミットをプッシュします。これにより、他の開発者は、些細なコミットの巨大な壁とは対照的に、機能上の違いを生み出すコミットを見ることができます。リグレッションが発生した場合のデバッグが容易になります。
異なるバージョンを維持するために古いリビジョンから分岐するなど、リビジョン間を行き来することが予想されるアプリケーションである場合、クリーンで正確なコミット メッセージを持つことは、プロジェクトにとって価値のあるツールであると考えます。
まれな状況でビルドを壊す可能性がほとんどない増分更新に取り組んでいるだけなら、それらが非常に正確であることについてあまり気にしません.
履歴に追加して最新バージョンを見るだけであれば、問題ありません。
私は最近、誰かが 2 つのブランチに大きなパッチを適用して「マージ」したプロジェクトに取り組んでいました。機能を導入した変更を探して、それに付随するテストを確認して見つけました。多くの時間を無駄にしました。
また、マージによって導入される新しい次元によって、二分法がより困難になることもわかります。もはや左右だけではありません。
コミット コメントは後で注釈ビューに表示されることを思い出そうとしています。したがって、変更自体ではなく、コミットされた変更の意図と全体的な効果を説明しようとしています。