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

一般的なベストプラクティスが何であるかを知りたいです。プロジェクトが動作状態（適切にビルド、すべてのテストに合格など）になるようにgitコミットを強制するか、壊れたコードをコミットしても問題ありませんか？

たとえば、この要件を放棄した場合、コミットにより柔軟に対応できます（アプリが動作状態にない場合でも、論理チャンクとして使用します）。ただし、それを強制すると、特定のコミットを後で選択できる柔軟性が得られます...

私は通常このルールに従います：

• ブランチへのマージのたびに、プロジェクトを動作状態のままにする必要があります。master
• 各マージメインラインへdevelopの分岐がなければならない（と、それは、少なくとも構築する必要があります）作業状態でプロジェクトを残します。
• 他の各コミットには、変更が行われた理由、変更の目的、プロジェクトのどの部分が影響を受けたかを説明するという主要な目標があります。プロジェクトを稼働状態のままにするなど、他のすべての目標はオプションです。

リポジトリのローカルクローンを使用して、開発中に快適に作業できるようにします。

壊れたコードを定期的にコミットし、他の開発者がコードを利用できるようにする準備ができたら、素晴らしい機能を使用します。

git rebase -i HEAD~4

これにより、破損した可能性のある中間（この場合は4つ）のコミットを1つの適切なコミットに圧縮できます。これらのコミットを圧縮する方法を選択できるエディターが表示されます。通常、最初のコミットには「ピック」コミットをマークし、他のコミットには「スカッシュ」マークを付けます。

その後、1つのアトミックコミットをプッシュできます。実際、新しい機能が本当に準備ができている場合は、「git cvsexportcommit」を使用して既存のCVSリポジトリに作業を追加します。

バージョン管理の2つの大きな利点は、開発者が以前のバージョンの作業を回復できることと、開発者が異なる、競合する可能性のある変更を同時に試すことができることです。バージョン管理により、開発者は失敗する可能性のあるアイデアを自由に試すことができます。

開発者は、ビルドするかどうかにかかわらず、定期的に作業を分岐してコミットすることをお勧めします。ブランチのコミットや壊れたコミットの許可を拒否することは、開発者を束縛し、ツールを十分に活用しないことです。

ただし、特定のブランチへのコミットが常にビルドされるように要求することは、優れたプラクティスです。多くの組織はさらに進んで、開発者が特定のブランチにコミットすることをまったく禁止しています。たとえば、開発者は自分の作業をメインの開発ブランチにマージする必要がありますが、開発から本番ブランチにそれらの変更をマージできるのはリード開発者のみです。

通常、両方のアプローチに従います。ボックスのローカルリポジトリで、必要なすべてをコミットします。チームの中央レポジトリにプッシュするとき、私は最初にインタラクティブなリベースを行い、コミットを論理パッケージにまとめます。通常、ストーリー（または欠陥）IDがコメントに含まれる、ストーリーごとに1つのコミット（私たちはかんばんベースのショップです）。

次に、中央の再現でJenkinsがリッスンし、ビルドとすべてのテストを開始します。何かが失敗した場合、一般に、別のコミットでビルドを修正してもらうことができます。見栄えが悪い場合は、不完全なコミットを元に戻すのは簡単です。

以来git commitリポジトリのみの独自のコピーに影響を与え、コミットすべての後に作業状態にするプロジェクトのための必要はありません。行った作業を保存したいときはいつでもコミットしてください。おそらく、良い経験則は、コミットメッセージで行った変更を記述することができる場合、コミットが適切であることです。

それgit pushは他のユーザーに影響します。プッシュする必要があるポリシーは、開発チームが決定する問題です。動作しないコードをメインブランチにプッシュすることはおそらく無意味ですが、動作しないコードを別のブランチにプッシュすることはおそらく大丈夫です（他の誰もそのブランチからビルドしようとしない限り）。

仕事でgit flowを使用しています。また、未完成または破損したコードもコミットします。特定の問題のために作成されたローカルまたはリモートのブランチにのみ到達するからです。タスクが完了すると、開発ブランチ（フローモデルの現在の作業コピーを表す）にマージされます。そのようにして、コードで共同作業を行い（プロジェクトリーダーを含む一部の同僚が別の都市にいます）、互いに助け合うことができます。

ただし、それはあなたと同僚がどのように考えているかに依存します。個人的には、より大きなリファクタリングなどの変更履歴が必要になる可能性があるため、ブランチのコミットは大丈夫だと思います。

gitはルールを課していないため、最終的にはあなたとあなたが仕事をする人、またはあなたのために働く人次第です。

私のプラクティスは、意図的にシステムを著しく悪化させるコミットを避けることです。各コミットはリファクタリングするか、何らかの要件を実装する必要があります。悪いコミットをして、それをプッシュする前に発見した場合、履歴から削除するために修正またはリベースします。

各コミットはリファクタリングまたは何らかの要件の実装として独立している必要があるため、これによりプルリクエストでgitログを読みやすくなると思います。近い将来に復活するデッドコードを追加することは、リファクタリングとしてカウントされます。これらは私の「論理チャンク」です。

コミットをどのように構成するかについては、引き続き柔軟に対応できます。たとえば、事前にテストを記述できますが、テストスイートが失敗を報告しないように、すべてのテストをスキップ済みとしてマークし、実装が完了したらスキップします。

あなたがブランチと良いコミットメッセージを使用していると仮定すると、それが明確なコミットメッセージでブランチ上で「壊れた」コードをコミットすることは、あなたのチームがそれが良い作業慣行であることに同意する限り問題ありません。

また、gitリポジトリをローカルで複製するため、ローカルコミットを含むローカルブランチが発生する可能性があります。次に、すべてが機能するようになったら、マスターまたは他のブランチにマージし、さまざまな「壊れた」コミットで作業ブランチを削除します。

私にとっては、受け入れられるものをチームに同意することがすべてです。一部のチームはブランチでも壊れたコードを受け入れませんが、他のチームは受け入れます。