バージョン履歴は本当に神聖なものですか、それともリベースする方が良いのでしょうか？

私はMercurialのマントラ¹に常に同意していましたが、Mercurialがリベース拡張機能にバンドルされ、gitで一般的なプラクティスであるため、本当に「悪いプラクティス」と見なされるかどうかは疑問です。使用を避けるのに十分なほど悪い。いずれにせよ、プッシュ後のリベースが危険であることは承知しています。

OTOH、私は5つのコミットを1つにパッケージ化して見栄えを良くすることを目指しています（特に本番ブランチで）が、個人的にはいくつかの機能の一部のコミットを見ることができる方が良いと思いますたとえ気の利いたものでなくても、実験は行われますが、「Xでやってみましたが、結局Yほど最適ではありません。ZをベースとしてZを行う」のようなものを見ると、勉強している人にとっては価値がありますコードベースを作成し、開発者の一連の思考に従ってください。

私の非常に意見のある（馬鹿げた、内臓、偏った）視点は、プログラマーがミスを隠すためにリベースを好むということです...

ですから、私の質問は次のとおりです。実際にそのような「有機コミット」（つまり、改ざんされていない履歴）を実際に使用する価値があると思いましたか？どちらを選んでも、なぜそれがあなたのために働くのですか？（履歴を保持するために他のチームメンバーを使用するか、代わりに履歴を変更します）

¹あたりGoogleのDVCS分析は、のMercurialに「歴史は聖なるです」。

歴史は、神聖な存在ではありません。DVCSの「ツリー」を2つの部分に分割できます。

• 過去のあなたは、コードの現在の状態に達しているかを正確に表示が含まれている/履歴。歴史のこの部分は時間とともに成長します

• 現在あなたが現在あなたのコードの進化を作るために取り組んでいる部分。このヒントの歴史の大部分は、ほぼ常に同じサイズです。

あなたがリリースまたは使用したコードはすべて過去の一部です。過去は神聖なものです。セットアップを再現するか、回帰の原因を理解する必要があるからです。あなたは過去を決して書き直してはならない。gitでは、一度マスターになったら何も書き換えることはありません。マスターは履歴の過去の部分です。Mercurialには、「ツリー」の過去の部分を追跡し、その不変性を強制するパブリックフェーズの概念があります。

コードの現在の部分は、現在作業中のチェンジセットです。使用可能、バグフリー、適切にリファクタリングしようとしている機能ブランチ。過去の部分をよりきれいでシンプルで使いやすくするので、それを書き換えるのは完全に良い考えです。Mercurialはドラフトフェーズでこれを追跡します。

はい。履歴が改善される場合は、リベースしてください。Mercurialは、あなたがすべきでないものをリベースしている場合、あなたが自分の足で撃つことを防ぎます。

すべての間違いが非表示にする必要があるわけではありません。たとえば、誤ってバイナリファイルをリポジトリにコミットしたことがあります。履歴を改ざんするのは、コミットすべきでないファイルのように、フォールトが履歴自体に限定されていない場合のみです。

多くの小さな依存する変更とは対照的に、1つの大きな凝集的な変更がある場合、コードレビューは非常に簡単です。

私が新しい機能に取り組むとき、私は私のブランチで多くの小さな変更をコミットするのが好きです。パッチを提出する準備ができたら、これらの小さなコミットを、その機能に必要なすべての新しいコードを表す1つの大きなコミットにまとめます。これは、リベースが便利な場所です。

一方、コミットが互いに関係がない場合、リベースは不適切です。複数の機能追加は別々のコミットである必要があります（そして理想的には別々のブランチから来る）。

あなたの質問は、歴史を順序付けられたコード変更のセットとして説明し、オーガニックが将来の読者に開発プロセスへの手がかりを与えるかどうかを尋ねます。それでも、リリース/統合エンジニアとして、私は歴史をコードとは思わないことがよくあります。私は自分の歴史が語る物語、それが保持している制度的知識、そしてそれが問題を迅速にデバッグできるかどうかにもっと夢中になっています。

私自身でさえ、オーガニックワークフローがこれをうまくやるとは思わない。コーディングの際にDVCSを重視する品質（安価なブランチ、クイックコミット、リモートへの早期保存など）は、会社の統合マネージャーとして評価するものではありません。 私が発行するgit rebase、git merge、git diff、とgit applyはるかに頻繁にその役割よりもgit addかgit commit。のようなツールrebaseにより、与えられたコードを機能するものから保守可能なものに変換することができます。

不合理なコミットやあいまいなコミットは有用ではありませんが、他の人に配布するのではなくコードを機能させることが主な関心事である場合、組織的に簡単に書くことができます。のようなコミットCase 15: Fixed a problem、またはRefactored <cranky legacy feature>私がそれらをオーサリングするときでさえ、私のメンテナンス自己を縮めます。ただし、「増分」コミットのようなブラックアウトの怒りを引き起こすものはありません。開発者が先日私に渡したこのトピックブランチを考えてみましょう：

$ git log production..topic --oneline
f9a1184 incremental update
156d299 incremental commits
e8d50b0 new incremental updates
511c18c incremental updates, refactor
1b46217 incremental upgrade
9e2b3b8 incremental update
fa68a87 incremental update

これらは悪です。それは、ファウストゥス博士のために設計されたDVCSのようなものです。迅速かつ簡単なソース管理を提供します。あなたは私にあなたのコードメンテナーの魂です。すべての遅延コミットは利己的な行為です。私たちの多くはそれらを書きますが、私たちの未来には、論理的で複製可能なデバッグ可能な歴史もあります。なんらかの方法がなければ、それはできませんrebase。

失敗した実験については、（新しく作成された）コミットメッセージでそれらを説明してみませんか？一年後、私は半完成スニペットを必要としません。中止された試行の記録が必要です。また、もう一度試行するのに十分な愚かさがある場合は、簡単な説明が必要です。世界には多くの成功したワークフローがありますが、私は故意に壊れたコードを本番用のコードベースにコミットする理由を考えるのに苦労しています。

何も神聖であるべきではありませんが、あなたがしていることの正当な理由があることを確認してください。リベースは適切に使用すると非常に強力ですが、他の強力なツールと同様に、不注意に使用すると混乱を招き、問題を引き起こす可能性があります。

個人的には、最終テストを実行して機能をメインブランチにマージする前に、トランク（またはメイン開発ブランチ）に対してローカルフィーチャブランチをリベースすることは非常に便利です。そうすれば、実際にマージする前にマージの競合などに対処することができます。

私見、実験は通常、ベースラインではなく棚または一時的なブランチに属します。これに従えば、問題はないはずです。すべてのコミットが論理的に健全であり、何らかの価値を追加するからです。