動作しないコードをコミットしても大丈夫ですか？

動作するコードのみをコミットすることを要求するのは良い考えですか？

このコミットでは、リポジトリを次のように動作状態のままにする必要はありません。

• ...設計の初期段階にありますが、コードはまだ安定していません。
• ...あなたはプロジェクトの唯一の開発者です。物事がうまくいかない理由を知っています。さらに、壊れたコードをコミットして誰かの作業を停止することはありません。
• ...現在、コードは機能しません。これに大きな変更を加えます。物事がugくなる場合に戻るポイントを得るために、コミットしましょう。

• ...チェーンが長く、壊れたコードがローカルブランチに存在する場合は問題ありません。すなわち

  1. ローカルファイル
  2. ステージングエリア
  3. ローカルブランチでコミット
  4. リモートの個人機能ブランチでのコミット
  5. リモートdevelopブランチとマージ
  6. リモートmasterブランチとマージ
  7. リモートreleaseブランチとマージ

• ...早くコミットし、頻繁にコミットします。

したがって、上記のリンクされた質問では、回答の大半は、コンパイルできないコードをコミットしても、ローカルおよび機能ブランチでは問題ないと述べています。どうして？壊れたコミットの価値は何ですか？

追加：ローカルブランチでは、好きなことは何でもできると言っている、非常に投票されたコメントがいくつかあります。ただし、質問の技術的な側面には興味がありません。むしろ、ベストプラクティス-業界で長年働いてきた人々が最も生産性を高めてきた習慣-を学びたいと思います。

膨大な量の素晴らしい答えに驚いています！彼らは、コードを整理するためにブランチを使用するのが十分ではないという結論に至ります。

分岐理念の一つ（に分岐戦略とコードラインポリシーの開発セクション高度なSCM分岐戦略 -も読んPERFORCEのベスト・プラクティス、そのPDFファイルを他のいくつかの詳細に入る）あなたはincompatabileポリシーに分岐するということです。

コードラインポリシーは、コードラインのフェアユースと許容されるチェックインを指定し、コードラインSCMの重要なユーザーマニュアルです。たとえば、開発コードラインのポリシーでは、リリース用ではないことを明記する必要があります。同様に、リリースコードラインのポリシーは、承認されたバグ修正への変更を制限する必要があります。このポリシーでは、チェックイン中の変更を文書化する方法、必要なレビュー、必要なテスト、およびチェックイン後のコードラインの安定性の期待についても説明できます。ポリシーは、文書化された強制可能なソフトウェア開発プロセスにとって重要なコンポーネントであり、SCMの観点からは、ポリシーのないコードラインは制御不能です。

（Perforceベストプラクティスから）

たとえば、リリースをビルドするブランチ「リリース」（または「マスター」）と、開発者が作業コードをチェックインする「トランク」（または「開発者」）があるとします。これらはブランチのポリシーです。「作業コード」が「dev」ブランチポリシーの一部であることに注意し、壊れたコードをdevブランチにコミットしないでください。多くの場合、CIサーバーがこれらのブランチに接続され、壊れたコードをdevにチェックインすると、すべてのブランチが台無しになり、ビルドが壊れることがあります。

ただし、機能しない部分的なコードをチェックインすることが適切な場合があります。これらのインスタンスでは、分岐する必要があります-トランクとの互換性のないポリシー。この新しいブランチでは、ポリシーを決定し（「壊れたコードはOK」）、コードをコミットできます。

コードラインを分岐する必要があるかどうかを判断する簡単なルールが1つあります。ユーザーが別のチェックインポリシーを必要とするときに分岐する必要があります。たとえば、製品リリースグループには厳密なテストを実施するチェックインポリシーが必要な場合がありますが、開発チームには部分的にテストされた変更の頻繁なチェックインを許可するポリシーが必要な場合があります。このポリシーの相違には、コードラインブランチが必要です。ある開発グループが別の開発グループを見たくない場合

（Perforceベストプラクティスから）

これは、強力な企業マインドセットを持つ中央サーバーベースのSCMからのものであることを認識してください。核となるアイデアはまだ良いです。これらはしばしば暗黙的に考えられます-テストされていない開発コードをリリースブランチにチェックインしません。それがポリシーです。

ブランチです。このブランチではコードが壊れてコミットされてしまう可能性があります。

Linus Torvaldsが提案した哲学の1つは、創造的なプログラミングは一連の実験のようなものであるべきだということです。あなたにはアイデアがあり、それに従ってください。常にうまくいくとは限りませんが、少なくとも試してみました。開発者に創造的なアイデアを試すように促し、それを行うには、その実験を試すのは安く、回復するのは安くなければなりません。これは、gitコミットが非常に安価（高速で簡単）であるという真の力です。それは、この創造的なパラダイムを開き、開発者が他にはないものを試すことができるようにします。これはgitの解放です。

はい、リリースブランチでない限り。

個人のブランチでは、実験がうまくいかなかった場合、すべてが進行し、その後廃棄されます。それがDVCSの主な利点の1つです：自由

壊れたコードをコミットする価値？：コラボレーションと実験

はい、大丈夫です。

コンパイルできないコードを（少なくともブランチで）コミットすることのポイントは、コードが進行中の場合もありますが、これまでに行われた作業は保存および/または他の人と共有する価値があることです

私のプラクティスは次のとおりです。

• 最初にテストを書く
• wip（進行中の作業）コミットは良い
• 頻繁に（1日以内に複数）コミットし、早期に（「作業」手順を保存して）
• コミットのたびにプッシュします（ハードドライブがクラッシュした場合/バスがヒットした場合）。
• 常に最初にブランチで作業する
• 可能であれば、作業コードをマスターにマージするだけです
• マスターマージの前にwipsをスカッシュするためのgitでのインタラクティブなリベース

主な問題、そしておそらくあなたが触れている問題は、基本的に機能し、ビジネスに非常に必要な（したがって「マスター」である必要がある）機能があるが、いくつかの失敗したテストがある場合です。ここでのオプションの1つは、現在進行中のテストを実行することです。ただし、テストが修正されることはなく、テストを修正する代わりに単純に「保留」する他の領域にパターンを設定する可能性があるため、これには危険が伴います。

別のオプションは、ブランチを一時的に使用して展開することです。これは特定の状況で役立ちますが、一般的に推奨されておらず、持続可能ではありません。

おそらく最良の選択肢は、基本的にソフトウェア開発に対してより専門的なアプローチを取ることであり、コミットされたコードに対して実際にテストを行う必要があります。これは、多くの人が想像するコーディングではなく、ソフトウェア開発の「ハード」な部分であることがよくあります。より良いアプローチには、より良い初期推定、リソース割り当て、優先度設定などが必要になる可能性があります。さらに、アジャイル開発中に、十分な時間を確保し、発生時とグルーミング中の問題を修正するために十分な規律を使用して-ポインティングセッションを行う必要があります。

「完了」の意味に注目してください-コードとテストが作成され、リファクタリングされて動作することを意味します。「ほぼ完了、テストの作成/修正/リファクタリングが必要なだけ」などのコメントを聞いた場合、それは行われません。機能が技術的に完全にならずに行われたと言うことは、ジュニアプログラマの最も一般的な間違いの1つです。

壊れているかどうかに関係なく、コミットの価値は、コードがサーバーにコミットされることです。プロフェッショナルな環境では、そのサーバーは安全で冗長であり、バックアップを実行しています。私が一日中働いている場合、コミットとは、ローカルマシンで起こったことが何であれ、コードが生き残るようにすることです。ハードディスクは死にます。ラップトップは紛失または盗難に遭います。建物が焼損した場合でも、リポジトリサーバーのバックアップを利用できます。

このように考えてください。開発者としてあなたがする最も破壊的なことの1つは、チームの他の開発者がタスクに取り組むことを止めることです。

作業コードのみをコミットするという哲学は、リポジトリ内の同じ単一のトランクで作業する開発チームから来ています。今では狂気のように思えるかもしれませんが、10年前はこれが通常の作業方法でした。安定したリリースを作成するときにブランチが表示されますが、新しい機能を実装するためにブランチで作業する開発者の考えはほとんど前代未聞です。

ご使用の環境が、コミットが他の開発者にすぐに影響しないことを意味する場合、頻繁にコミットします。コードのセキュリティが強化され、コードの間違いを簡単にロールバックできます。また、多くのソース管理システムにより、コミットされたコードに対するコード保護が提供されます（すべてではありません）。

今、他の開発者と共有されているブランチとのマージが機能することを確認し、このレベルに昇格するコードがすべてコンパイルされ、すべての単体テストと他のチームベースの健全性チェックに合格することを確認します...パブでビールを買い続けます...

バージョン管理を使用する方法について独断的になり始める前に、バージョン管理を使用する理由を考える価値があります。

バージョン管理にコミットすると、将来の参照のためにコードの状態がフリーズします。他のものはすべてこれから外れます。差分を見てパッチを作成することは、スナップショット間でコードがどのように変化したかを見るだけです。ブランチとタグは、スナップショットを整理するための単なる方法です。他の開発者とコードを共有することは、特定のスナップショットを見るだけです。

いつコミットする必要がありますか？合理的な機会があれば、将来コードの状態（または変更を説明するコミットメッセージ）を確認します。

Gitは、スナップショットを整理する方法に関して非常に多くの柔軟性を提供します。中央リポジトリがないため、状態を「メイン」リポジトリにプッシュせずにコードを他の開発者と共有できます。ブランチを簡単に作成、マージ、削除して、メインコードのナラティブから一連の状態の詳細を分離できます。ローカルでコミットして、現在の開発のフォローを取り消すことができます。その後、すべてを1つのコミットにまとめてから、他の人に見せるようにします。特定のリビジョンにタグを付けて、後で簡単に見つけられるようにすることができます。

キス。小さなプロジェクトの開発の初期段階で単一の開発者に最適なことは、10年前のミッションクリティカルなシステムで100人の開発者が作業している場合に行う必要があるものとはまったく異なります。ソフトウェア開発プロセスでは、他の誰かがあなたにそうするように言ったからといって、不要なアーティファクトを作成しないでください。

ブランチのビルド/リリース

破損したコードを意図的にビルドブランチにコミットすることはできません。継続的に統合されているブランチ、またはリリースまたは毎日のビルドが行われるブランチは、常に潜在的に解放可能な状態である必要があります。

他のブランチ：状態を頻繁に保存

プライベートブランチまたは機能ブランチの場合、多くの場合、目標は異なります。頻繁にコードをチェックインする（動作するかどうかに関係なく）ことが望ましい場合があります。一般に、現在の状態に巻き戻す必要がある場合はいつでもコミットする必要があります。

保存された状態が大きな利点を提供するこれらの例を考えてみましょう。

• グローバルな検索と置換を実行する直前にコミットを実行すると、問題が発生した場合に1回の操作でツリーを元に戻すことができます。
• 複雑なコードをリファクタリングしながら一連の暫定コミットを実行して、プロセスで何かが壊れた場合に二分したり巻き戻したりできるようにします。
• いつでも現在の作業ツリーの状態に戻ることができる一方で、実験的なものを試したい場合は、コミットを実行したり、新しいブランチを開始したり、タグを作成したりできます。

壊れたコードベースをコミットしても、それがローカルであれば問題ありません。

どうして？

• 開発のセーブポイントとしてコミットを使用することが不可欠です
• 製品の開発中に使用された思考のパターンを示しています。
• これは、共同作業を中断されません。

ただし、プログラマーのチームが存在する場合、プログラミングハウスの哲学は最優先事項であり、個々のコミット動作に優先します。すべての進行状況を記録することを決定するプログラミングハウスもあれば、機能を解決するコードのみをコミットすることを決定するプログラミングハウスもあります。この場合、壊れたコミットの値（ソフトウェア管理の観点からはcost）は悲惨です：

1. さらなる機能に使用される時間は現在、エラーの修正に費やされています...
2. 開発カットが満たされていません...
3. 製品は時間通りに出荷されません

これら3つの効果を指数関数的に会社のメルトダウンにカスケードすることで、他のポイントを追加することができます...もちろん、これは悪いコードを常習的に慢性的にコミットする効果でなければなりません。

壊れたコードをコミットしても大丈夫だとは思わない。

どうなりますか

• 緊急のホットフィックスが必要です。コードベースは壊れた状態です。ロールバック、修正、展開を余儀なくされます。

• あなたが壊れたコードをコミットしたことを知らずに、他の誰かが同じブランチで働き始めます。彼らは彼らの変化が何かを壊したと考えて「赤いニシン」を追いかけているかもしれません。

• あなたは会社を辞めるか、休暇に行くか、何らかの理由で仕事に行くことができません。同僚は、何が壊れているのか、なぜ壊れた状態でコミットされているのかを見つけるために、深く掘り下げる必要があります。

• 誰かがあなたの「壊れたコード」をデプロイしますか？これは、個人データまたは支払いプロバイダーで作業している場合、「ゲームオーバー」になる可能性があります。

@WarrenTへの返信

誰もが機能ブランチで作業する理想的な世界では、機能しないコードをコミットしても機能する可能性があることに同意します。私は大規模なプロジェクトに取り組んできましたが、それでも複数の人が1つの機能ブランチで作業しなければならない場合がありました。また、リリースが数週間先であり、翌日に修正する予定であるため、人々がメインブランチに「動作しない」コードをコミットするのを見てきました。これらはすべて災害の候補であり、私はそれらがどんな犠牲を払っても回避されるべきだと強く信じています。

動作しないコードをコミットしてもよいかどうかを判断するのに役立ついくつかの質問：

1. 働きすぎですか？
2. チームメイトは常にビルドを壊していますか？
3. あなたのコードベースは混乱していて、一見悪くなることはありませんか？

上記のいずれかに「はい」と答えた場合、はい、機能しないコードをコミットしてもかまいません。

できるだけ早く修正し、適用可能な単体テストでカバーし、ビルドを壊したことを謝罪することを忘れないでください。