「コメントアウトされた」コードのチェックイン
わかりました、これは私の現在の仕事でいくらかの摩擦を引き起こした何かであり、私は本当にそれを期待していませんでした。社内でのソフトウェア開発はここでの新しい概念であり、コーディングガイドラインの最初のドラフトを作成しました。
「コメントアウトされた」コードをリポジトリにチェックインしないでください。私がこれを述べた理由は、リポジトリがファイルの完全な履歴を保持しているためです。機能コードを削除する場合は、完全に削除してください。リポジトリは変更を保持するため、変更内容を簡単に確認できます。
これは、別の開発者がこの方法をとるのはあまりにも制限的であると信じているという点で、いくらかの摩擦を引き起こしました。この開発者は、彼が取り組んでいるが不完全なコードをコメント化できるようにしたいと考えています。このコードは、以前にチェックインされることはなく、どこにも保存されませんでした。 TFSを使用するので、変更を保留することが最も適切なソリューションになることを提案しました。ただし、デプロイされている場合とされていない場合がある部分的な変更をチェックインできるようにしたいため、これは受け入れられませんでした。
最終的には、継続的インテグレーションを最大限に活用し、開発用Webサーバーに自動的にデプロイするようになる予定です。現在、Webサーバーまたはデータベースサーバーの開発バージョンはありませんが、すべてすぐに変更されます。
とにかく、あなたの考えは何ですか？ 「コメントアウトされた」コードがリポジトリにあると便利だと思いますか？
このトピックについて他の人から話を聞くことは非常に興味があります。
編集：わかりやすくするために、私たちはプライベートブランチを使用していません。もしそうなら、私はあなたのプライベートブランチであなたがやりたいことをしますが、コメントアウトされたコードをトランクや共有ブランチにマージしないでください。
編集：プライベートまたはユーザーごとのブランチを使用しない正当な理由はありません。それは私が同意しない概念ではありません。まだそのように設定していません。おそらくそれが最終的な中立だろう。ここでは、TFSシェルビングを使用します。
異なる経験を持つ他の人がいるかもしれませんが、鉱山では、半分完成したコードをチェックすることは恐ろしい考えです、期間。
私が学んだ原則を以下に示します。
- 頻繁にチェックイン-少なくとも1回、できれば1日に何度もチェックイン
- 完全な機能のみをチェックイン
- 最初と2番目の競合（たとえば、機能を動作させるのに1日以上かかる）の場合、タスクは大きすぎます-小さな完了可能なタスクに分割します。
これの意味は：
- コメントアウトされたコードは機能しないため、チェックインしないでください。
- コメントは有効なアーカイブ戦略ではないため、まだ完成していないコードでも、廃止されているコードでも、コメントしてチェックインしても意味がありません。
要約すると、NO！コードが次の段階に進む準備ができていない場合は（IntTest/QA/UAT/PreProd/Prod）、トランクまたはマルチ開発者ブランチにコミットしないでください。限目。
編集：他の回答とコメントを読んだ後、コメントしたコード（ban）は必ずしも良い考えではないと私は付け加えます（わからない）とにかくそれを強制する方法）。私が言うことは、あなたはチームの全員に私が上記の哲学に賛同してもらうべきだということです。私が取り組んでいるチームは、それを心から受け入れています。その結果、ソース管理はフリクトンのないチームメンバーであり、仕事を完了するのに役立ちます。
その哲学を受け入れない人々は、通常 壊れたウィンドウ を引き起こし、ソース管理にしばしば不満を感じます。彼らはそれをせいぜい必要悪であり、最悪の場合は避けるべきものだと考えています。これは、チェックインの頻度が低くなることを意味します。つまり、チェンジセットが巨大でマージが困難であること、フラストレーションが高まること、チェックインをさらに回避することなどです。これは最終的には態度の問題であり、実際にはプロセスの問題ではありません。それに対して精神的な障壁をかけるのは簡単です。本当にダイエットを望まないのにダイエットしない理由を見つけるのと同じように、機能しない理由を見つけるのは簡単です。しかし、人々doがそれを実行したいと考え、習慣を変えることに専念している場合、結果は劇的です。効果的に販売するのはあなたの負担です。
「決して」がガイドラインで使用するのに適していることはめったにありません。
コメントアウトされたコードをチェックインするのが適切な場合の良い例が同僚にあります。それが不完全で、アクティブな状態でチェックインするとアプリケーションが破損する場合があります。
適切に管理された変更管理システムでは、ほとんどの場合、コメントdeadコードは不要です。しかし、すべてのコメント付きコードが「死んだ」わけではありません。
コメントアウトされたコードは、履歴を維持する目的でneverにチェックインする必要があります。それがソース管理のポイントです。
人々はここで多くの理想を話している。おそらく他の誰とも違って、私は "現実の世界"が時々私の仕事を中断して、複数の中断を伴う複数のプロジェクトに取り組む必要があります。
時には、現実には、部分的に完成したコードをチェックインする必要があります。コードを紛失するか、不完全なコードをチェックインするリスクがあります。どんなに小さな仕事でも、いつでも「仕上げ」する余裕はありません。しかし、私はnotすべてのコードをチェックインせずにラップトップをネットワークから切断します。
必要に応じて、部分的な変更をコミットするために独自の作業ブランチを作成します。
コメントアウトしたコードを残す1つのケース：
// This approach doesn't work
// Blah, blah, blah
それが問題への明白なアプローチであるが、それはいくつかの微妙な欠陥を含んでいるとき。確かに、リポジトリはそれを持っていますが、リポジトリはその道を下らないように将来誰にも警告しません。
コメントアウトされたコードをチェックインすることは絶対にお勧めしません。しかし、絶対に禁止するつもりはありません。 時々（まれに）コメントアウトされたコードをソース管理にチェックインすることが適切です。 「絶対にしない」と言うのは制限が多すぎます。
私たちは皆、これらの点に同意すると思います：
- デッドコードをソース管理にチェックインしない
- 壊れた（機能していない）コードをソース管理にチェックインしないでください。少なくともneverはトランクに、ごくまれにプライベートブランチYMMVにチェックしてください。
- デバッグのために一時的にコメントアウトしたり、何かを壊したりした場合は、コードを正しい形式に戻すまで、コードをチェックインしないでください。
一部の人は、一時的に削除されたコード、または次のドキュメントとして少量のコメント化されたコードを含む段階的だが不完全な改善など、他のカテゴリがあると言っています、または非常に短い（理想的には1行）コメントアウトされたコードのスニペットで、決して追加しないでくださいコメントアウトされたコードには、コメントアウトされた（そして削除されただけではない）理由と、コメントアウトされたコードの予想される有効期間を示すコメントが必ず付いているはずです。たとえば、「次のコードは良いよりも害が大きいのでコメント化されていますが、リリースXXXの前に置き換える必要があります。」
上記のようなコメントは、お客様の出血を止めるための修正プログラムを提供していて、最終的な修正をすぐに見つける機会がない場合に適しています。修正プログラムを配布した後、コメントアウトされたコードは、まだ修正が必要なものがあることを示しています。
コメントアウトされたコードはいつチェックインしますか？一例として、近い将来に何らかの形で再度追加する必要がある可能性が高いと思われるものを一時的に削除する場合があります。コメントアウトされたコードは、これが不完全であることを直接思い出させるためのものです。確かに、古いバージョンはソース管理されており、さらに何かが必要であることを示すフラグとして[〜＃〜] fixme [〜＃〜]コメントを使用できます。ただし、場合によっては（頻繁ではないにしても）コードの方が適切なコメントです。
また、コードの1行（場合によっては2行）を削除してバグを修正した場合、その行をneverre-へのコメントでコメントアウトすることがありますその理由でそのコードを有効にします。この種のコメントは明確、直接、そして簡潔です。
Rex M氏は次のように述べています。1）完全な機能のみをチェックインする、2）[If]タスクが大きすぎる-完了可能な小さなタスクに分割する。
応答：はい、これは理想的です。運用コードで作業していて、修正する必要がある緊急の重大な問題がある場合、どちらのオプションも実現できないことがあります。タスクを完了するために、しばらくの間、フィールドにコードのバージョンを配置する必要がある場合があります。これは、問題の根本的な原因を見つけようとするときのデータ収集コードの変更に特に当てはまります。
より一般的な質問で尋ねられる特定のインスタンスについて...開発者がコメントアウトしたコードを、誰にも見えないがその開発者（そしておそらく開発者が協力している誰か）が見ないプライベートブランチにチェックインしている限り、害はほとんどありません。ただし、その開発者は、そのようなコードをトランクまたは同等のものに（ほとんど）配信しないでください。トランクは常に構築され、常に機能する必要があります。トランクに未完成のコードを配信することは、ほとんどの場合非常に悪い考えです。開発者に未完成または一時的なコードをプライベートブランチにチェックインさせる場合、トランクに配信する前にコードをスクラブすることを忘れないように開発者に依存する必要があります。
他の回答へのコメントに応じて明確にするために、コードがコメント化されてチェックインされている場合、コードがコメント化された時間の長さでコメントされていないドロップがあった場合、コードは機能すると私は期待しています。もちろん、リファクタリングツールは常にリファクタリングにコメントを含めるとは限りません。ほとんどの場合、コメントアウトされたコードを本番環境に配置すると、コードは洗練されたコメントとして機能するために存在し、散文よりも具体的であり、そこで何かを行う必要があります。寿命の長いものではありません。
最後に、すべてのソースファイルでコメント化されたコードを見つけることができる場合は、何か問題があります。 anyの理由でコメントアウトされたコードをトランクに配信することはまれなイベントです。これが頻繁に発生する場合、それは乱雑になり、その価値を失います。
neverは条件が強すぎると思います。
私はコメントアウトし、チェックインし、テストを実行し、考え、次のリリース後にコメントを削除する傾向があります。
一般的に、コメントアウトされたコードをチェックインすることは間違っています。元の作者ではなく、コードを読んだり修正したりする必要のある人々の間で混乱が生じるためです。いずれにせよ、3か月が経過した後、元の作者がコードについて混乱することがよくあります。
コードは会社またはチームに属しており、仲間にとって物事を簡単にするのはあなたの責任であるという信念を私は支持します。保持されている理由についてコメントを追加せずにコメント化されたコードをチェックインすることは、次のように言うことと同じです。
これがなぜここにあるのかについて混乱しても結構です。私のニーズはあなたのニーズよりも重要なので、私がこれを行ったのはそのためです。私はあなたや他の誰かに正当化する必要を感じていません。なぜ私はこれをしたのですか？
私にとってコメントアウトされたコードは通常と見なされます無礼のサイン思いやりのない同僚から。
コメントアウトされたコードはチェックインしないでくださいという原則に概ね同意します。ソース管理システムは共有リソースであり、あなたの同僚はある程度、それを個人のスクラッチパッドとして使用しています。これは、特にコードベースの共有所有権のアイデアを購読している場合は、他のユーザーにはあまり配慮されていません。
コメントアウトされたコードを見る次の開発者は、それが進行中の作業であることを理解していません。彼はそれを自由に変更できますか？デッドコードですか？彼は知りません。
同僚の変更がチェックイン可能な状態でない場合、同僚はそれを終了するか、小さな変更を加えることを学ぶ必要があります。
「展開される場合と展開されない場合がある部分的な変更のチェックイン」-おそらくそれはまたテストされるかもしれないかテストされないかもしれないことを意味しますか？これは、非常に不安定なコードベースへの滑りやすい斜面です。
NOWのような小さな機能やバグ修正を追加する必要がある場合、次の3分以内にファイルを修正する必要があります。開発中のコードがいくつかあります。実用的なニーズは、戦場の実用的な理想を支配するものです。
これは、2つの方法の考え方に根本的な違いがあることを示しています。満足していると感じている作業コードのみをチェックインし、保存する価値があると考える人と、作業をチェックインしてリビジョン管理を行うことで、データの損失を防ぐことができます。
私は後者を「彼らのリビジョン管理システムを貧乏人のテープバックアップとして使いたい人」と特徴づけていますが、それは私がどのキャンプにいるのかについて私の手先をひっくり返すでしょう。:-)
私の推測では、あなたは「良いコード」の陣営であり、彼は「働くコード」の陣営だと思います。
[編集]
コメントから、そうだと思いました。
私が言ったように、私はあなたと一緒ですが、私が言うことができる限り、これは少数派の意見です。したがって、それを運用する唯一の方法として、開発標準にそれを実際に組み込むことはできないと思います。とにかく標準にしたい場合はそうではありません。優れたリーダーが知っていることの1つは、彼らに命令を決して出さないことです知っている従わないでしょう。
btw：Goodエディターは古いバージョンを維持するのに役立ちます。たとえば、Emacsで私はkeeped-old-versionsとKeeped-old-versionsを10に設定しました。これにより、ファイルの最後の10回の保存が維持されます。あなたは、revision-control-as-backup群衆に対するあなたの議論を助ける方法としてそれを検討するかもしれません。しかし、あなたは議論に勝つことは決してありません。
チェックアウトされたコードをチェックインする別の理由：
あなたは既存のコードを変更していて、見過ごされがちで、おそらく一見すると正しく見えるかもしれない微妙なバグを見つけました。コメントアウトして、修正をその場所に置き、何が起こっているのか、なぜ修正されたのかについてコメントを追加します。それをチェックインして、修正に関するコメントがリポジトリにあるようにします。
私の経験では、開発者スイッチはコメント化されたコードです。
場合によっては、新しいバックエンドが並行して構築され、アクティブ化スイッチがソース管理でコメント化されます。
ブルームーンで一度必要になる奇妙な機能が、顧客が必要としない場合は、そのように実装されることがよくあります。これらは通常、セキュリティまたはデータ整合性のバイパスのリスクが高いため、開発以外ではアクティブにしないでください。それを使用してコードのコメントを外す開発者を最初に要求することが、コードを取得する最も簡単な方法のようです。
おそらくここでの本当の問題は、開発者が不完全なコードをチェックインできるようにするべきかどうかでしょうか？
この方法は、継続的インテグレーションを実装するという指定の目標に反するように思えます。
場合によります。説明の目的でそこに残されている場合は、たぶん。リファクタリング中に役立つ可能性があります。そうでなければ、そして一般的には、そうではありません。また、未完成のコードをコメントアウトすることは、失敗しやすく、時間を浪費することになります。コードを細かく分割し、機能するときにチェックインするのがよいでしょう。
私の見解：開発者が自分のブランチで、または自分のサンドボックス領域で作業している場合、彼らは好きなようにチェックインできるはずです。共有ブランチ（機能ブランチ、チームのブランチ、またはもちろんMAIN /トランク）にコードをチェックインするときは、コードをできるだけ原始的なものにする必要があります（コメントアウトされたコードやFIXMEなどはありません）。
コメントアウトされたコードをリポジトリにチェックインしないでください。これがソースコード管理の目的です。
私の経験では、プログラマーがコメント化されたコードをチェックインするとき、それは彼/彼女が正しい解決策が何であるかわからず、他の誰かがその決定を下すことを期待してソースに代替の解決策を残した方が幸せだからです。
コードが複雑になり、読みづらくなります。
ライブシステムから呼び出されない、半分完成したコード（ソース管理のメリットが得られる）をチェックインしても問題はありません。私の問題は、コードが除外されることになったジレンマが説明されていないコメント付きコードのセクションを見つけることです。
「ネバー」はルールが強すぎると思います。私は、人々がコメント付きのコードをリポジトリにチェックインするかどうかについて、個人的な余裕を残すために投票します。最終的な目標は、「純粋なリポジトリ」ではなく、コーダの生産性でなければなりません。
その緩やかなバランスをとるために、コメントアウトされたコードに有効期限があることを誰もが知っていることを確認してください。コメントされたコードが1週間使用され、アクティブにならなかった場合は、誰でも削除できます。 （「1週間」をあなたの気分に合ったものに置き換えてください。）そのようにして、あなたはそれを見たときに、人々の個人的なスタイルにあまり干渉することなく、乱雑さを殺す権利を留保します。
コメントアウトされたコードは「無駄」であると考えられます。
あなたはチーム環境で働いていると思います。自分で作業していて、コードを 'todo'でコメント化して戻ってくると、それは異なります。しかし、チーム環境では、コメントアウトされたコードがチェックインされると、そこにとどまるはずであり、満足よりも多くの苦痛を引き起こす可能性が高いと考えて安全です。
あなたがピアコードレビューをしているなら、それはあなたの質問に答えるかもしれません。別の開発者があなたのコードをレビューし、「なぜコメントアウトされたコードが「何とか」しようとしているのはなぜですか」と言った場合、コードはコードレビューに失敗しているので、とにかくそれをチェックするべきではありません。
コメントアウトされたコードは、他の開発者に質問を投げかけるだけなので、時間とエネルギーを浪費します。
「why」という質問をする必要があります。コードはコメント化されています。いくつかの提案：
「ビジネスルールがわからない」ためにコードをコメントアウトしている場合は、「スコープクリープ」に問題がある可能性があります。コードベースを「いいはずですが、時間がない」という要件でコードベースを汚さないようにしてください。実装する」-明確なコードと実際にそこにあるものをテストして、それをクリーンに保ちます。
「それが最善の方法であるかどうかわからない」ためにコードをコメントアウトしている場合は、コードをピアレビューしてください！時代は変わりつつあります。2年後に今日書いたコードを見て、それは恐ろしいと思います。しかし、あなたが「知っている」ことをより良く行うことができるビットをコメントアウトすることはできませんが、今のところ方法を見つけることができません。コードベースを長期間維持している人に、より良い方法があるかどうかを判断させましょう。コードを記述してテストし、機能させて、次に進むだけです。
「何かが機能しない」ためにコードをコメントアウトしている場合は、 FIX IT ！一般的なシナリオは "壊れたテスト"または "todo's" です。あなたがこれらを持っているなら、あなたはそれらを修正するか、単にそれらを取り除くことによって、あなた自身の時間を大幅に節約するでしょう。一定期間「破損」する可能性がある場合は、永久に破損する可能性があります。
これらの潜在的なシナリオ（およびここで言及しなかったもの）はすべて、時間と労力を浪費しています。コメントアウトされたコードは小さな問題のように見えるかもしれませんが、チーム内のより大きな問題の指標となる可能性があります。
ソース管理履歴がコメントアウトするのではなく、説明と共にコメントアウトをチェックインするのではなく、何かを行う「古い方法」を説明できるようにするという考えは、理論的には良い考えです。
ただし、現実の世界では、何らかの公式なレビュープロセス（定期的にのみ行われる）の一部である場合、または何かが機能しない場合、および開発者でない限り、作業中のファイルのソース管理履歴を見ることはありません。理由がわかりません。
それでも、基本的に3つ以上のバージョンを振り返ることはありません。
これは部分的には、ソース管理システムではこの種のカジュアルなレビューを簡単にできないためです。通常、古いバージョンをチェックアウトするか、古いバージョンと比較する必要があります。2つのバージョンが表示されるだけで、何が変更されたかを一目で把握できる変更点についての簡潔なビューはありません。
部分的には、それは人間の本性とチームのニーズの組み合わせです。何かを修正する必要があり、数時間でそれを修正できる場合、1か月間「ライブ」でなかった古いバージョンのコードを調査するのに1時間を費やすことはほとんどありません（各開発者が多くの場合、多くのリビジョンを戻すことを意味します）、そこに何かがあることをたまたま知っている場合（たとえば、現在行っていることに関連する何かを変更することについての議論を覚えている場合など）。
コードが削除されてチェックインされると、すべての意図と目的（完全なロールバックの限定された目的を除く）で、コードは存在しなくなります。はい、それはバックアップの目的で存在しますが、コードライブラリアンの役割を担う人がいなければ、迷子になります。
現在のプロジェクトのソース管理ツリーは、約4名のエンジニアのチームで約10週間前のものであり、約200のコミットされた変更リストがあります。私のチームは、しっかりしていて準備ができているものがあるとすぐにチェックインするほどには上手くいきません。そのため、すべての重要な変更をキャッチするために、コードのすべての部分のコード履歴を読み取ることに依存することはかなりおおざっぱです。
現在、私は初期開発モードでプロジェクトに取り組んでいます。これは、メンテナンスモードのプロジェクトとは大きく異なります。同じツールの多くが両方の環境で使用されますが、ニーズはかなり異なります。たとえば、何かを構築するために2人以上のエンジニアがある程度密接に連携して作業する必要があるタスクがよくあります（たとえば、クライアントとサーバーがある種のサーバー）。
サーバーを作成している場合は、クライアントが使用するドラフトインターフェイスのコードを作成し、それを完全に機能しない状態でチェックして、クライアントを作成しているエンジニアが更新できるようにします。これは、あるエンジニアから別のエンジニアにコードを送信する唯一の方法はソース管理システムを経由するというポリシーがあるためです。
タスクに十分な時間がかかる場合は、おそらく2人で作業するためにブランチを作成する価値があります（ただし、これは私の組織のポリシーに反しています-エンジニアと個々のチームリーダーには必要な権限がありません）ソース管理サーバー）。結局のところ、それはトレードオフです。そのため、私たちは「常に」または「決して」ポリシーをあまり導入しないようにしています。
私はおそらくそれが少しナイーブだったと言うことによってそのようなコメントされていないコードエバーポリシーに対応するでしょう。意図的であるかもしれませんが、最終的にはその目的を達成する可能性は低いです。
この投稿を見ると、先週チェックインしたコードに戻って、コメントアウトされた部分は削除されますが、最終的には機能しませんでしたが（機能しましたが）、また再び望まれる可能性はほとんどありません。
特に、コードのコメントに使用される言語タグがブロックで記述されている場合は、ソースコード管理システムでコメント付きコードをチェックインする際に、特に注意が必要です。
/* My commented code start here
My commented code line 1
My commented code line 2
*/
個々の行ごとではなく、次のようにします。
// My commented code start here
// My commented code line 1
// My commented code line 2
（あなたはアイデアを得る）
私が極端に注意する理由は、テクノロジーによっては、使用しているdiff/mergeツールに非常に注意する必要があるためです。特定のソースコード管理システムと特定の言語では、diff/mergeツールは簡単に混乱する可能性があります。たとえば、ClearCaseの標準のdiff/mergeは、.xmlファイルのマージには悪名高いものです。
コメントブロックの行が正しくマージされない場合は、prestoのコードがシステムでアクティブにならないはずのときにアクティブになります。コードが不完全でビルドが壊れている場合は、すぐに見つけられるので、それはおそらく最小の悪です。
しかし、コードがビルドをパスすると、そこにあるべきではないときにアクティブになる可能性があり、CMの観点からは、それは悪夢のシナリオになる可能性があります。 QAは通常、そこにあるはずのものをテストしますが、そこにあるはずのないコードについてはテストしません。そのため、コードは、気付かないうちに本番環境で終了し、コードがそこにあるときにコードがそこにあることがわかるまでに、すべきではありません。メンテナンスのコストは何倍にもなりました（「バグ」は本番環境で、または顧客によって、最悪の場所または時間で発見されるため）。
1）早期にチェックインすることと、2）リポジトリを常に稼働状態に維持することの間には、明らかに緊張関係があります。開発者が数人以上いる場合は、1人の開発者が自分の個人的なワークフローのために他のすべての人を悩ませることはできないため、後者の方が優先順位が高くなります。 とはいえ、最初のガイドラインの値を過小評価しないでください。開発者はあらゆる種類のメンタルフェンスポストを使用します。個別のワークフローは、優れた開発者がこれらの余分なXを絞り出す1つの方法です。マネージャーとして、これらのすべてのニュアンス（天才であり、開発者全員が馬鹿でない限り失敗するでしょう）を理解しようとしないでください。むしろ、開発者が独自の意思決定を通じて最善を尽くせるようにします。
あなたはコメントでプライベートブランチを使用しないと述べています。あなたへの私の質問は、なぜそうではないのですか？さて、TFSについては何も知りません。ですから、理由があるのかもしれません。ただし、1年間gitを使用した後は、優れたDVCSがこの緊張を完全に拡散すると言わざるを得ません。置換を作成しているときにコードをコメントアウトすると便利な場合がありますが、他のユーザーにコードを使用している場合は、コードを読み込めなくなります。ローカルで分岐できることは、ダウンストリームの開発者が一時的な混乱を心配する（または通知する）必要なく、個々のプロセスに対して有意義なコミットを維持できることを意味します。
コーラスをエコーします。どんな犠牲を払ってもこれを思いとどまらせてください。それはコードを読みにくくし、現時点ではアプリケーションの一部でもないそのコードの良し悪しを不思議に思う人を残します。リビジョンを比較することで、いつでも変更を見つけることができます。大規模な手術があり、コードがまとめてコメントアウトされている場合、開発者はチェックイン/マージの改訂ノートにそれを記録しているはずです。
不完全な/実験的なコードは、完全に開発されるブランチにある必要があります。ヘッド/トランクは、常にコンパイルされ、出荷されるメインラインである必要があります。実験的なブランチが完成したら、それを受け入れて、head/mainlineにマージする必要があります。サポートドキュメントが必要な場合は、IEEE標準（IEEE 1042）でも説明されています。
" Scar Tissue "は、私がコメント化したコードです。バージョン管理システムが広く使用される前の数日間、 Code Monkeys は、機能を元に戻す必要がある場合に備えて、コメント化されたコードをファイルに残します。
「瘢痕組織」をチェックインできるのは、
- プライベートブランチとがある場合
- エラーなしでコードをコンパイルする時間がないおよび
- あなたは長期休暇を取っていますand
- Visual Source Safe[〜＃〜]または[〜＃〜]を使用する場合のように、VCSを信頼していません。
[編集] - 微妙なバグがあり、誤ったコードがリマインダーとして残されていない場合、再導入される可能性があります。 （他の回答からの良い点）。
自由に利用できる堅牢なVCSシステムがたくさんあるので、＃4の言い訳はほとんどありません Gitが最良の例です 。
それ以外の場合は、VCSをアーカイブおよびコードディストリビューターにしてください。他の開発者があなたのコードを見たい場合は、彼に差分をメールで送って、彼が欲しいものを直接適用させてください。いずれにせよ、マージでは、2つのファイルのコーディングがどのように、またはどのように分岐したかは関係ありません。
それがコードであるため、瘢痕組織は、よく書かれたコメントよりも気が散ることがあります。コードとしての性質上、瘢痕組織が彼の変更と関係があるかどうかを把握するために、メンテナンスプログラマーはメンタルCPUサイクルを費やします。瘢痕が1週間か10歳かは関係ありません。瘢痕組織をコードに残すと、コードのあとがきを解読しなければならない人に負担がかかります。
[編集]区別する必要がある2つの主要なシナリオがあると付け加えます。
- 個人開発、個人プロジェクトのコーディングまたはプライベートブランチへのチェックイン
- チェックインされるコードが運用環境に配置されることを目的としたメンテナンス開発。
瘢痕組織に「いいえ」と言うだけです！
壊れている可能性があり、まだ使用されていないアクセス可能なコードが、完全に利用できない同じコードよりもチェックインされているのを確認したいと思います。すべてのバージョン管理ソフトウェアでは、トランクとは別の「作業コピー」を使用できるため、代わりにこれらの機能を使用することをお勧めします。
新しいので、機能しない新しいコードはトランクで問題ありません。おそらく、すでに機能しているものは何も壊しません。動作するコードが壊れた場合は、ブランチに移動するだけでよいので、他の開発者は（必要な場合）そのブランチをチェックアウトして、何が壊れているかを確認できます。
リポジトリはコードのバックアップです。私がコードに取り組んでいるがそれが完了していない場合は、コメントアウトして、1日の終わりにチェックインしてください。そうすれば、私のハードドライブが一晩で死んでも、仕事を失うことはありません。午前中にコードをチェックアウトして、コメントを外して続行できます。
私がコメントアウトする唯一の理由は、夜間のビルドを壊したくないからです。
新しい変更がテストに合格したからといって、コメントアウトされたコードをチェックインすることは有効であるはずだと思います。
以前の変更を確認するためにいくつかのバージョンに戻る必要があり、それが現在パフォーマンスに影響を与える場合、それは非常に煩わしいでしょう。
コメントアウトされたコードは良い履歴である場合がありますが、コードがコメントアウトされた日付を入力してください。その後、コメントアウトされたコードは不要であることが判明しているため、近くで作業している人はコメントアウトされたコードを削除できます。
誰かがそのコードをコメント化したことを知っておくとよいでしょう。そのため、何らかの根拠が必要な場合は、質問することができます。
私は新しい機能を記述し、ユニットテストに合格し、それをチェックインし、他のユーザーに使用を許可して、その動作を確認することを好みます。
わかりません-変更を加える前に常にoriginal行をコメントアウトします-気が変わった場合、元に戻すのに役立ちます。はい、チェックインします。
ただし、以前のチェックインから古いコメントコードを削除しています。
何が変更されたかを確認するためにdiffログを見ることができることは知っていますが、それは苦痛です-コードの最後の変更をすぐに確認できるのは素晴らしいことです。
C++では、コメント化されたコードに#if 0を使用し、それが正当であることを発見しました。 リファクタリングツールはまだ機能しているため、技術的にはほぼ維持されています。そして、それは構文の強調表示によって明確にcoloredです。
私はそのような機能がすべての人に役立つと思います：
- このコードは機能していません
- それはまだここに属しています
- そして、それは関連しているので、この時点で非常に目に見えるはずです。
実際のコメントがない場合は常にコメント付きのコードを削除します。このコードの何が特別で、なぜ機能しないのになぜそれほど重要なのかを説明します。
まだ完成していないために開発者が一部のコードをコメントアウトしている場合、これに対処する正しい「ソース管理」方法は、その開発者がそのコードまで自分の別のブランチにコードを保持することですisチェックインの準備ができています。
DVCS（git、Bazaar、Mercurialなど）を使用すると、中央リポジトリを変更する必要がないため、これは非常に簡単です。それ以外の場合は、開発者が十分な時間（日）を要する特定の機能に取り組んでいる場合は、開発者にサーバー上の独自のブランチを提供することについて話し合うこともできます。
いくつかの状況では、コメント化されたコードのチェックインに問題はありません。これは、より良い方法がある可能性があるため、開発者はソースへの変更を追跡できるためですそれでもメインリポジトリにチェックインする準備が整っていません。
明らかに、コメントアウトされたコードをチェックインする開発者は、別のブランチで作業し、必要に応じてトランクブランチからの変更をマージする必要があります。
このワークフローで開発者を支援するのは、VCSシステム次第です（gitは、これを非常にうまく機能させる優れたVCSシステムの1つです）。
チェックアウト/変更されたファイルをネットワークバックアップドライブにダンプする小さなツールを作成するのがいいでしょう。そうすれば、心ゆくまでコンテンツを変更して作業をバックアップできますが、実験的または未完成のコードをチェックインする必要はありません。