プッシュの最終コミットが機能している限り、中間コミットが壊れていても大丈夫ですか？

関連： すべてのgitコミットはプロジェクトを動作状態のままにする必要がありますか？

次のコミットをローカルで行うと仮定します。

• データベーススキーマを変更して、アプリケーションを破壊します。

• データベーススキーマと再度互換性があるようにアプリケーションを更新します。

両方のコミットをプッシュする限りmaster、動作状態のままです。ただし、履歴バージョンは壊れています。

私はgit rebase -iコミットを一緒につぶすために使用できることを知っています。ただし、結果のコミットは大きくなり、説明が少なくなります。コミット履歴を検索して、何かを変更した理由を調べる必要がある場合は、元のコミットが自分が何をしたのか、そしてなぜなのかを示したいと思います。

私の質問は：

• masterで壊れた履歴コミットが原因で問題が発生した人はいますか？

• もしそうなら、個々のコミットメッセージと変更を破棄せずに、そのような困難を避ける簡単な方法はありますか？

服装のブランチ戦略に大きく依存しますが、開発ブランチでコミットが破損していることは一般的に非常に理にかなっていると思います。それらを束にして卵を割ってオムレツを作らなければなりません。

マスターを汚染せずに個々のコミットを維持する簡単な方法は、ブランチを使用することです。そこに破壊的な/実験的なものを置くことができますので、マスターブランチの履歴を汚染することなくきめ細かい履歴を持つことができます。

壊れたコミットは「ちょうど起こる」ものであり、世界の終わりを意味するものではありません。原則として、したがって履歴バージョンを含めて、壊れたコードを故意にチェックインするべきではないことを示す小さなしつこい声がありますが、それは私が戦争に行くものではありません。

Gitの賞賛されている分岐モデルにより、たとえばチームがgitflowまたはその簡易バージョンを採用している場合など、特定の分岐からのコミットの破損を防ぐことができます。「クリーンマスター」ポリシーを持つもの。この場合、最終的な作業バージョンをマージコミットとしてチェックインできます。この場合、（破損した）履歴バージョンはリポジトリで利用できますが、メインラインはオフです。

チームがそのような分岐モデルを採用していない場合は、ロット全体をマスターしてマスターするための有効な言い訳があります。

いいえ、大丈夫ではありません。

あなたがgit bisect（そしてそのキラー機能を愛していない）あなたがやったことがあるなら、あなたはすべてのコミットが構築される歴史の価値を知っています。

bisectビルド中に多くのコミットがある場合git bisect skip、最後の適切なコミットを見つけるのが困難になるs がたくさんあります。

機能ブランチを終了してマスターにマージする場合は、マージする前にブランチをクリーンアップして、履歴を明確にして構築します。

masterで壊れた履歴コミットが原因で問題が発生した人はいますか

はい。バックポート、リバート、およびバイセクトはより困難です。履歴も読んでいます（以下を参照）。

もしそうなら、個々のコミットメッセージと変更を破棄せずに、そのような困難を避ける簡単な方法はありますか？

ブランチはまともな解決策ですが、私が知っているわけではありません。

ただし、個々のコミットを破棄する（または潰す）のは正しいことだと思います。

開発中、特にTDDを実行する場合、早期にコミットすることが適切であることがよくあります。あなたはあなたがやっていることの完全なトレースが欲しいので、あなたはバックトラックすることができます、または物事がうまくいかなくなったときを正確に把握します コミットします。

ただし、機能/変更をプッシュする準備ができたら、コミットはパッケージ化された変更です-理想的にはアトミックなので、可能な限り他の変更から独立して[レビュー、リベース、マージ、チェリーピック、リバート、注釈で表示]できます。

プロジェクトの履歴を見ると、ソフトウェアの変更は単独で評価する必要があります。ビルドしますか？テストが付属していますか？動作しますか？それは何をするためのものか？その機能を提供するには、どのファイルを変更する必要がありましたか？

コミットをアセンブルする必要があると（可能であればマージによって助けられます）、それは難しくなります。したがって、プッシュする前に履歴をクリーンアップすることが適切だと思います。たとえそれが、あなたがどこに着いたかを追跡することを意味していてもです。

短い答え：はい

テスト：

テスト駆動開発とは、壊れるテスト（つまり、失敗を示すテスト）を記述することです。
次に、テストを機能させるコードを記述します。

開発：

小さくコミットし、頻繁にコミットします。
各コミットはロールバックポイントです。間違ったパスにいることに気付いた場合、以前のポイントに比較的簡単にロールバックできます。コミットがきめ細かい場合、正しいポイントにロールバックできます。

警告：

これは意味しません

1）壊れたコードをマスターにチェックインします。
2）全員がレビューできるように、すべてのマイクロコミットをプッシュする必要があります。

ブランチを使用して作業を行います。レビュープロセスのマイクロコミットを潜在的に圧縮して、適切にコメントを付けた論理的に別個のユニットにします。gitを使用している場合、元のコミットセットを失うことはありません。マスターにマージされるレビュープロセス用の新しいより論理的なコミットセットを作成できます。

コミットがローカルであり、他の人にプッシュされない限り、それは大丈夫であるだけでなく、実際に作業するのに良い方法だと思います。壊れたコードを他人にプッシュしないでください。