機能していないコードをコミットしても大丈夫ですか？
このコミットでは、リポジトリを次のように作業状態にしておく必要はありません。
- ...設計の初期段階にあり、コードはまだ安定していません。
- ...プロジェクトの唯一の開発者です。物事がうまくいかない理由を知っています。さらに、あなたは壊れたコードをコミットすることによって誰かの仕事を止めません。
- ...現在、コードは機能しません。これに大きな変更を加えます。事態が醜くなった場合に戻るために、コミットしましょう。
...チェーンが長く、ローカルブランチに壊れたコードが存在しても問題ありません。つまり.
- ローカルファイル
- ステージングエリア
- ローカルブランチでコミット
- リモートの個人機能ブランチでコミット
- リモート
developブランチとマージする - リモート
masterブランチとマージする - リモート
releaseブランチとマージする
...早くコミットし、頻繁にコミットします。
したがって、上記のリンクされた質問では、大部分の回答は、コンパイルできないコードをコミットすることは、ローカルブランチと機能ブランチでは問題がないと述べています。 なぜですか？コミットが失敗した場合の値は何ですか？
追加：ローカル投票では人は何でも好きなことができると言って非常に投票されたコメントがいくつかあります。ただし、質問の技術的な側面には興味がありません。むしろ、私はベストプラクティスを学びたいと思います。つまり、業界で長年働いてきた人々が最も生産的に習得している習慣です。
膨大な量の素晴らしい答えに驚いています！ branchesを使用してコードを整理するのに十分ではないという結論に導きます。
分岐の哲学の1つ（セクション 高度なSCM分岐戦略）の分岐戦略とコードラインポリシーの開発 -も読みます Perforceのベストプラクティス 、PDFですが、他の詳細について説明します）非互換性ポリシーに基づいて分岐すること。
コードラインポリシーは、コードラインのフェアユースと許容されるチェックインを指定し、コードラインSCMの基本的なユーザーマニュアルです。たとえば、開発コードラインのポリシーには、リリース用ではないことを明記する必要があります。同様に、リリースコードラインのポリシーでは、承認されたバグ修正への変更を制限する必要があります。ポリシーには、チェックインされる変更を文書化する方法、必要なレビュー、必要なテスト、およびチェックイン後のコードラインの安定性の期待についても記述できます。ポリシーは、文書化された強制可能なソフトウェア開発プロセスにとって重要なコンポーネントであり、SCMの観点から、ポリシーのないコードラインは制御不能です。
（Perforceのベストプラクティスから）
たとえば、リリースのビルド元のブランチ「release」（または「master」）と、開発者が作業コードをチェックインする「trunk」（または「dev」）のブランチがあるとします。これらは支店の方針です。 「動作するコード」は「dev」ブランチポリシーの一部であることに注意してください。壊れたコードをdevブランチにコミットしないでください。多くの場合、これらのブランチに接続されたCIサーバーや、壊れたコードをdevにチェックインすると、全員のブランチが台無しになり、ビルドが壊れる可能性があります。
ただし、機能しない部分的なコードをチェックインすることが適切な場合があります。これらのインスタンスでは、1つを分岐する必要があります-トランクとの互換性のないポリシー。この新しいブランチでは、ポリシー（「壊れたコードは問題ない」）を決定して、それにコードをコミットできます。
コードラインを分岐する必要があるかどうかを判断する簡単なルールが1つあります。ユーザーが異なるチェックインポリシーを必要とする場合、コードラインを分岐する必要があります。たとえば、製品リリースグループでは、厳密なテストを実施するチェックインポリシーが必要な場合がありますが、開発チームでは、部分的にテストされた変更を頻繁にチェックインできるポリシーが必要な場合があります。このポリシーの相違により、コードラインブランチが必要になります。ある開発グループが別の開発グループに会いたくない場合
（Perforceのベストプラクティスから）
これは、強力な企業マインドセットを備えた中央サーバーベースのSCMによるものであることを理解してください。核となるアイデアはまだ良いです。これらはしばしば暗黙的に考えられます-テストされていない開発コードをリリースブランチにチェックインしません。それはポリシーです。
したがって、ブランチは、このブランチが壊れたコードを含んでいてコミットする可能性があると言います。
Linus Torvaldsが提案した哲学の1つは、創造的なプログラミングは一連の実験のようなものであるべきだということです。あなたにはアイデアがあり、それに従います。いつもうまくいくとは限りませんが、少なくとも試しました。あなたは開発者に創造的なアイデアを試すことを奨励したいと思います、そしてそれを行うには、その実験を試すことは安く、回復することは安くなければなりません。これは、Gitコミットの真のパワーが非常に安価（高速かつ簡単）であることです。それは、開発者が他にないかもしれないものを試すことを可能にするこの創造的なパラダイムを開きます。これはgitの解放です。
はい、それがリリースブランチでない限り。
個人のブランチでは、すべてがうまくいき、実験がうまくいかなかった場合は破棄できます。これがDVCSの主な利点の1つです。freedom
壊れたコードをコミットする価値は？：collaborationおよびexperimentation
はい、それは大丈夫です。
（少なくともブランチ内の）コンパイル不可能なコードをコミットすることのポイントは、コードが進行中の作業である場合がありますが、これまでに行われた作業は、保存したり、他のユーザーと共有したりする価値があるということです
私の慣行は：
- 最初にテストを書く
- wip（進行中の作業）コミットは適切です
- 頻繁に（1日で複数回）コミットし、早期に（「作業」ステップを保存）
- コミットのたびにプッシュします（ハードドライブがクラッシュしたり、バスがヒットした場合）。
- 常に最初に支店で働く
- 可能な場合は、作業コードをマージしてマスターするだけです
- マスターマージの前にwipsをスカッシュするgitのインタラクティブリベース
主な問題、そしておそらくあなたが触れている問題は、基本的には機能し、ビジネスで非常に必要とされる（したがって「マスター」である必要がある）機能がいくつかあり、失敗するテストがある場合です。ここでの1つのオプションは、現時点で先に進むことができる保留中のテストを実行することです。ただし、テストが修正されることはなく、壊れたテストを修正するのではなく、単に「保留」する他の領域にパターンを設定する可能性があるため、これには危険が伴います。
別のオプションは、ブランチを一時的に使用して展開することです。これは特定の状況で役立ちますが、一般的には推奨されず、持続可能ではありません。
おそらく、最良のオプションは、基本的にはソフトウェア開発に対してより専門的なアプローチを取り、コミットされたコードに対して実際に機能するテストを必要とすることです。多くの場合、これはソフトウェア開発の「難しい」部分であり、多くの人が想像するコーディングではありません。より優れたアプローチには、より良い初期見積もり、リソース割り当て、優先順位設定などが必要になる可能性が高く、アジャイル開発中、十分な時間を確保し、問題が発生したときとグルーミング-ポインティングセッションの両方で問題を修正するのに十分な規律を使用します。
「完了」の意味に焦点を当てます。つまり、コードとテストが記述されており、リファクタリングされて機能しています。 「大部分が完了し、テストを記述/修正/リファクタリングする必要があるだけの場合、そのようなことは行われません。技術的に完全でなくても機能が実行されると言うのは、ジュニアプログラマーの最も一般的な間違いの1つです。
壊れているかどうかにかかわらず、コミットの価値は、コードがサーバーにコミットされることです。プロフェッショナル環境では、そのサーバーは安全で冗長性があり、バックアップを実行しています。私が1日中作業している場合、コミットとは、自分のコードがローカルマシンで発生したすべてのことを確実に生き残るための1つの形です。ハードディスクが死ぬ。ラップトップは紛失または盗難に遭います。建物が焼失しても、リポジトリサーバーのバックアップを利用できます。
このように考えてください。開発者としてあなたがする最も破壊的なことの1つは、チームの他の開発者がタスクに取り組むのを止めることです。
機能するコードのみをコミットするという哲学は、リポジトリ内の同じ単一のトランクで作業する開発チームから来ています。今では狂気のように思えるかもしれませんが、10年前は、これが通常の作業方法でした。安定したリリースを作成したいときにブランチが表示されますが、ブランチで新しい機能を実装するために作業している開発者の考えは、ほとんど前例がありませんでした。
あなたの環境があなたのコミットが他の開発者にすぐに影響を及ぼさないことを意味するなら、頻繁にコミットします。これにより、コードのセキュリティが強化され、コードの間違いを簡単にロールバックできます。また、多くのソース管理システムは、コミットされたコード（すべてではありません）に対してコードを保護します。
ここで、他の開発者と共有するブランチとのマージが機能し、このレベルに昇格したすべてのコードがコンパイルされ、すべてのユニットテストと他のチームベースのサニティチェックに合格することを確認してください...パブでビールを買い続けます...
バージョン管理の操作方法について独断的に始める前に、バージョン管理を操作している理由について考えることは価値があります。
バージョン管理にコミットすると、将来の参照のためにコードの状態がフリーズします。それ以外のことはすべてこれに該当しません。差分を見てパッチを作成することは、スナップショット間でコードがどのように変更されたかを確認することです。ブランチとタグは、スナップショットを整理するための単なる方法です。他の開発者とコードを共有することで、特定のスナップショットを見ることができます。
いつコミットすべきですか？妥当な可能性がある場合は、将来、コードの状態（または変更を説明するコミットメッセージ）を確認します。
Gitを使用すると、スナップショットを整理する方法に関して非常に多くの柔軟性が得られます。中央リポジトリがないため、状態を「メイン」リポジトリにプッシュせずにコードを他の開発者と共有できます。ブランチを簡単に作成、マージ、削除して、一連の状態の詳細をメインコードの説明から分離できます。ローカルでコミットして、現在の開発のフォローを元に戻し、他の人に見せる前にすべてを1つのコミットにまとめることができます。特定のリビジョンにタグを付けて、後で見つけやすくすることができます。
[〜＃〜]キス[〜＃〜] 。小規模なプロジェクトの開発の初期段階で1人の開発者が最も効果的に機能することは、10年前のミッションクリティカルなシステムで100人の開発者が作業している場合に必要なこととはまったく異なります。ソフトウェア開発プロセスでは、誰かがあなたにそうするように言ったからといって、不必要な artifacts を作成することを避けるべきです。
ブランチのビルド/リリース
壊れたコードを故意にビルドブランチにコミットしないでください。継続的な統合が行われているブランチ、またはリリースや毎日のビルドが行われるブランチは、常に解放可能な状態である必要があります。
その他のブランチ：頻繁に状態を保存する
プライベートブランチまたは機能ブランチの場合、目標はしばしば異なります。コードの頻繁なチェックイン（機能しているかどうかにかかわらず）が望ましい場合があります。通常、現在の状態に巻き戻す必要がある場合はいつでもコミットする必要があります。
保存された状態が大きなメリットをもたらすこれらの例を検討してください：
- グローバルな検索と置換を実行する直前にコミットを実行すると、問題が発生した場合に1回の操作でツリーを元に戻すことができます。
- 複雑なコードをリファクタリングするときに一連の暫定コミットを実行して、プロセスで何かが壊れてしまった場合に二分したり巻き戻したりできるようにします。
- いつでも現在の作業ツリーの状態に戻れるようにしながら、実験的なことを試したい場合は、コミットを実行したり、新しいブランチを開始したり、タグを作成したりできます。
壊れたコードをコミットしても大丈夫だとは思いません。
どうなりますか
緊急のホットフィックスが必要です。コードベースは壊れた状態です。ロールバック、修正、展開を余儀なくされます。
他の誰かが、壊れたコードをコミットしたことを知らないまま、同じブランチで作業を開始します。彼らは彼らの変化が何かを壊したと考えて「赤いニシン」を追いかけているかもしれません。
会社を辞めるか、休暇を取るか、何らかの理由で仕事に出られない場合。あなたの同僚は、何が壊れているのか、なぜ壊れた状態でコミットされたのかを見つけるために深く掘り下げる必要があります。
誰かがあなたの「壊れたコード」を配備しますか？個人データを扱う場合、または支払いプロバイダーで作業する場合、これは「ゲームオーバー」になる可能性があります。
@ WarrenTに返信
誰もが機能ブランチで作業する理想的な世界では、機能していないコードをコミットしても機能する可能性があることに同意します。私は大規模なプロジェクトに取り組んできましたが、それでも複数の人が1つの機能ブランチで作業しなければならない場合がありました。また、リリースが数週間前にあり、翌日に修正する予定だったため、メインブランチに「動作しない」コードをコミットする人もいます。これらはすべて災害の候補であり、絶対に回避する必要があると私は強く信じています。
壊れたコードベースをコミットすることは、それがローカルである限り問題ありません。
なぜ？
- 開発のセーブポイントとしてコミットを使用することが不可欠です
- これは、製品の開発中に使用された思考のパターンを示しています。
- コラボレーションを壊さない。
ただし、プログラマーのチームがいる場合、プログラミングハウスの哲学が最優先であり、個々のコミット動作よりも優先されます。一部のプログラミングハウスはすべての進行状況をログに記録することを決定し、他の人は機能を解決するコードのみをコミットすることを決定します。この場合、壊れたコミットの値（コスト、ソフトウェア管理の観点から）は悲惨です。
- 機能を追加するために使用されていた時間がエラーの修正に費やされています...
- 開発カットが満たされていない...
- 商品は時間通りに発送されません
これらの3つの効果を指数関数的に企業のメルトダウンにカスケードする他のポイントを追加することができます...もちろん、これは悪いコードの慢性的な習慣的なコミットメントの効果でなければなりません。