「コメントアウトされた」コードのチェックイン[終了]

わかりました、これが私の現在の仕事でいくらかの摩擦を引き起こした何かであり、私は本当にそれを期待していませんでした。ここで組織されたソフトウェア開発はここでの新しい概念であり、いくつかのコーディングガイドラインの最初のドラフトを作成しました。

「コメントアウトされた」コードはリポジトリにチェックインしないでください。私がこれを述べた理由は、リポジトリがファイルの完全な履歴を保持しているためです。機能コードを削除する場合は、完全に削除してください。リポジトリは変更を保持するため、変更内容を簡単に確認できます。

このため、別の開発者がこの方法をとるのは制限が厳しすぎると考えているため、多少の摩擦が生じています。この開発者は、彼が取り組んでいるが不完全なコードをコメント化できるようにしたいと考えています。このコードは、以前にチェックインされることはなく、どこにも保存されませんでした。TFSを使用するので、変更を保留することが最も適切なソリューションになると提案しました。ただし、デプロイされている場合とされていない場合がある部分的な変更をチェックインできるようにしたいため、これは受け入れられませんでした。

最終的には、継続的インテグレーションを最大限に活用し、開発用Webサーバーに自動的にデプロイするようになる予定です。現在、Webサーバーまたはデータベースサーバーの開発バージョンはありませんが、すべてすぐに変更されます。

とにかく、あなたの考えは何ですか？「コメントアウトされた」コードがリポジトリにあると便利だと思いますか？

このトピックについて他の人から話を聞くことは非常に興味があります。

編集：わかりやすくするために、私たちはプライベートブランチを使用していません。私たちがそうした場合、私はあなたのプライベートブランチであなたがやりたいことをしますが、コメントアウトされたコードをトランクや共有ブランチにマージしないでください。

編集：プライベートまたはユーザーごとのブランチを使用しない正当な理由はありません。それは私が同意しない概念ではありません。まだそのように設定していません。おそらくそれが最終的な中立だろう。ここでは、TFSシェルビングを使用します。

異なる経験を持つ他の人がいるかもしれませんが、鉱山では、半完成したコードをチェックするのは恐ろしい考えです。

私が学んだ原則を以下に示します。

• 頻繁にチェックイン-少なくとも1回、できれば1日に何回もチェックインする
• 完全な機能のみをチェックイン
• 最初と2番目が競合する場合（たとえば、機能を動作させるのに1日以上かかる）、タスクが大きすぎる-完了可能な小さなタスクに分割します。

これの意味は：

• コメントアウトされたコードは機能しないため、チェックインしないでください。
• コメントは有効なアーカイブ戦略ではないため、まだ完成していないコードでも、廃止されるコードでも、コメントしてチェックインしても意味がありません。

要約すると、NO！コードが次の段階に進む準備ができていない場合（IntTest / QA / UAT / PreProd / Prod）：トランクまたはマルチ開発者ブランチにコミットしないでください。限目。

編集：他の回答とコメントを読んだ後、コメント付きのコードを禁止することは必ずしも良い考えではないと私は付け加えます（とにかくそれをどのように強制したかわかりません）。私が言うことは、あなたはあなたのチームの全員に私が上記の哲学に賛同するようにさせるべきだということです。私が取り組んでいるチームは、それを心から受け入れています。その結果、ソース管理はフリクションのないチームメンバーであり、仕事の遂行に役立ちます。

その哲学を受け入れない人々は通常、壊れたウィンドウを引き起こし、しばしばソース管理に不満を感じます。彼らはそれをせいぜい必要悪であり、最悪の場合は避けるべきものだと考えています。これは、チェックインの頻度が低くなることを意味します。つまり、チェンジセットが巨大でマージが困難であること、フラストレーションが増大すること、チェックインをさらに回避することが必要になることなどです。それに対して精神的な障壁をかけるのは簡単です。本当にダイエットを望まないのにダイエットしない理由を見つけるのと同じように、機能しない理由を見つけるのは簡単です。しかし、人々がそれを望んでいて、習慣を変えることに専心している場合、結果は劇的です。効果的に販売するのはあなたの負担です。

「決して」は、ガイドラインで使用するのに適した単語であることはめったにありません。

コメントアウトされたコードをチェックインするのが適切な場合の良い例が同僚にあります。それが不完全で、アクティブな状態でチェックインするとアプリケーションが壊れる場合があります。

ほとんどの場合、適切に管理された変更管理システムでは、デッドコードをコメント化する必要はありません。しかし、すべてのコメント付きコードが「死んだ」わけではありません。

コメントアウトされたコードは、履歴を維持する目的でチェックインしないでください。それがソース管理のポイントです。

人々はここで多くの理想を話している。おそらく他の誰とも違って、私は "現実の世界"が時々私の仕事を中断して、複数の中断を伴う複数のプロジェクトに取り組む必要があります。

時には、現実には、部分的に完全なコードをチェックインする必要があります。コードを失うリスク、または不完全なコードをチェックインするリスクがあります。どんなに小さな仕事でも、いつでも「仕上げ」する余裕はありません。しかし、すべてのコードをチェックインせずにラップトップをネットワークから切断することはありません。

必要に応じて、部分的な変更をコミットするために独自の作業ブランチを作成します。

コメントアウトしたコードを残す1つのケース：

// This approach doesn't work
// Blah, blah, blah

それが問題への明らかなアプローチであるが、それはいくつかの微妙な欠陥を含んでいるとき。確かに、リポジトリはそれを持っているでしょうが、リポジトリはその道を下らないように将来誰にも警告しません。

コメントアウトされたコードをチェックインすることは絶対に避けたいと思います。しかし、絶対に禁止するつもりはありません。時々（まれに）、コメントアウトされたコードをソース管理にチェックインすることが適切です。「絶対にしない」と言うのは制限が厳しすぎる。

私たちは皆これらの点に同意すると思います：

• デッドコードをソース管理にチェックインしない
• 少なくとも、ソースコントロールに分割（非機能）コードをチェック決して決して、トランクにだけ非常にまれ構内にYMMVを
• デバッグのために一時的にコメントアウトしたり、何かを壊したりした場合は、コードを正しい形式に戻すまで、コードをチェックインしないでください。

一部の人は、一時的に削除されたコードや、次に来るもののドキュメントとしてコメントアウトされた少量のコード、またはコメントの非常に短い（理想的には1行）スニペットを含む、段階的だが不完全な改善など、他のカテゴリがあると言っています決して追加しないでください何かを示すコードを出力します。コメントアウトされたコードには、コメントアウトされた（そして削除されただけではない）理由を説明し、コメントアウトされたコードの予想される存続期間を示すコメントが必ず付いているはずです。たとえば、「次のコードは良いというよりは害が大きいのでコメント化されていますが、リリースXXXの前に置き換える必要があります。」

上記のようなコメントは、お客様の出血を防ぐための修正プログラムを提供していて、最終的な修正をすぐに見つける機会がない場合に適しています。修正プログラムを配布した後、コメントアウトされたコードは、修正が必要なものがあることを示しています。

コメントアウトされたコードはいつチェックインしますか？一例として、近い将来、何らかの形で再度追加する必要がある可能性が高いと思われるものを一時的に削除している場合です。コメントアウトされたコードは、これが不完全であることを直接思い出させるためのものです。確かに、古いバージョンはソース管理されており、さらに何かが必要であることを示すフラグとしてFIXMEコメントを使用できます。ただし、場合によっては（頻繁ではないにしても）コードの方が適切なコメントです。

また、コードの1行（場合によっては2行）を削除することでバグを修正する場合、その行をコメントでコメントアウトして、その理由でコードを再度有効にしないようにすることがあります。この種のコメントは明確、直接、そして簡潔です。

Rex M氏は次のように述べています。1）完全な機能のみをチェックインする、2）[If]タスクが大きすぎる-完了可能な小さなタスクに分割する。

応答：はい、これは理想的です。運用コードで作業していて、修正する必要がある緊急の重大な問題がある場合、どちらのオプションも実現できないことがあります。タスクを完了するために、しばらくの間、フィールドにコードのバージョンを配置する必要がある場合があります。これは、問題の根本的な原因を見つけようとするときのデータ収集コードの変更に特に当てはまります。

より一般的な質問で尋ねられる特定のインスタンスについて...開発者がコメントアウトしたコードを、誰にも見えないがその開発者（そしておそらく開発者が協力している誰か）が見ないプライベートブランチにチェックインしている限り、害はほとんどありません。ただし、その開発者は、そのようなコードをトランクまたは同等のものに（ほとんど）配信しないでください。トランクは常に構築され、常に機能する必要があります。未完成のコードをトランクに配信することは、ほとんどの場合非常に悪い考えです。開発者に未完成または一時的なコードをプライベートブランチにチェックインさせる場合、トランクに配信する前にコードをスクラブすることを忘れないように開発者に依存する必要があります。

他の回答へのコメントに応じて明確にするために、コードがコメント化されてチェックインされている場合、コメント化されていない時間の長さでコメントされていないドロップがあった場合にコードが機能することを期待しています。明らかに、リファクタリングツールは常にリファクタリングにコメントを含めるとは限りません。ほとんどの場合、コメントアウトされたコードを本番環境に配置すると、コードは洗練されたコメントとして機能するために存在し、散文よりも具体的なものであり、そこで何かを行う必要があります。寿命の長いものではありません。

最後に、すべてのソースファイルでコメント化されたコードを見つけることができる場合は、何か問題があります。何らかの理由でコメント化されたコードをトランクに配信することはまれなイベントです。これが頻繁に発生する場合は、乱雑になり、その価値を失います。

決して強くない状態だと思います。

私はコメントアウトし、チェックインし、テストを実行し、考え、次のリリース後にコメントを削除する傾向があります。

一般に、コメントアウトされたコードをチェックインすることは間違っています。元の作者ではなく、コードを読んだり修正したりする必要のある人々の間で混乱が生じるためです。いずれにせよ、3か月が経過した後、元の作者がコードについて混乱することがよくあります。

コードは会社またはチームに属しており、同僚が物事を簡単にできるようにするのはあなたの責任であるという信念を支持します。保持されている理由についてコメントを追加せずにコメント化されたコードをチェックインすることは、次のように言うことと同じです。

なぜこのようなものがここにあるのか、混乱してしまってもかまいません。私の必要性はあなたのものより重要であり、それが私がこれをした理由です。私がこれをした理由を、あなたや他の誰かに正当化する必要はないと思います。

私にとって、コメントアウトされたコードは、通常、それほど思いやりのない同僚からの失礼な兆候と見なされます。

コメントアウトされたコードはチェックインしないでくださいという原則に概ね同意します。ソース管理システムは共有リソースであり、あなたの同僚は、ある程度、それを個人のスクラッチパッドとして使用しています。これは、特にコードベースの所有権を共有するというアイデアに同意している場合は、他のユーザーにはあまり配慮されていません。

次の開発者は、コメントアウトされたコードが進行中の作業であることを理解していません。彼はそれを自由に変更できますか？デッドコードですか？彼は知りません。

同僚の変更がチェックイン可能な状態にない場合、同僚はそれを終了するか、小さな変更を加えることを学ぶ必要があります。

「展開される場合とされない場合がある部分的な変更のチェックイン」-おそらくそれはまた、テストされるかもしれないかテストされないかもしれないことを意味しますか これは、非常に不安定なコードベースへの滑りやすい斜面です。

NOWのような小さな機能やバグ修正を追加する必要がある場合、次の3分以内にファイルを修正する必要があります。開発中のコードがいくつかあります。実用的なニーズは、戦場の実用的な理想を支配するものです。

これは、2つの考え方の根本的な違いを示しています。つまり、満足できる動作コードのみをチェックインし、保存する価値があると感じる人と、作業内容をチェックインして改訂管理を行うことで、データ損失を防ぐことができます。

私は後者を「リビジョン管理システムを貧乏人のテープバックアップとして使用したい」と特徴付けていますが、それは私がどのキャンプにいるのかについて私の手がかりになるでしょう。:-)

私の推測では、あなたは「良いコード」の陣営であり、彼は「働くコード」の陣営だと思います。

[編集]

コメントから、そうだと思いました。

言ったように、私はあなたと一緒にいますが、これが少数派の意見であると私が言うことができる限り近いです。したがって、それを運用する唯一の方法として、開発標準にそれを実際に組み込むことはできないと思います。とにかく標準にしたい場合はそうではありません。優れたリーダーが知っていることの1つは、彼らが従わないことがわかっている命令を決して与えないことです。

btw：優れたエディターは古いバージョンを維持するのに役立ちます。たとえば、Emacsで私はkeeped-old-versionsとkeep-old-versionsを10に設定しました。これにより、ファイルの最後の10回の保存が維持されます。あなたは、revision-control-as-backup群衆に対するあなたの議論を助ける方法としてそれを検討するかもしれません。しかし、あなたは決して議論に勝つことはありません。

私の経験では、開発者スイッチはコメント化されたコードです。

時々、新しいバックエンドが並行して構築され、アクティブ化スイッチがソース管理でコメント化されます。

ブルームーンに一度必要な奇妙な機能が、顧客が必要としない場合は、そのように実装されることがよくあります。これらは通常、セキュリティまたはデータ整合性のバイパスのリスクが高いため、開発以外でアクティブにしたくないものです。それを使用してコードのコメントを外す開発者を最初に要求することが、コードを取得する最も簡単な方法のようです。

チェックアウトされたコードをチェックインする別の理由：

あなたは既存のコードを変更していて、見落としがちで、おそらく一見すると正しく見えるかもしれない微妙なバグを見つけました。コメントアウトして、修正をその場所に置き、何が起こっているのか、なぜ修正されたのかについてコメントを追加します。それをチェックインして、修正に関するコメントがリポジトリにあるようにします。

おそらく、ここでの本当の問題は、開発者が不完全なコードをチェックインできるようにするべきかどうかです。

この方法は、継続的インテグレーションを実装するという指定された目標に反するように思えます。

場合によります。説明の目的でそこに残されている場合は、たぶん。リファクタリング中に役立つ可能性があります。そうでなければ、そして一般的には、そうではありません。また、未完成のコードをコメント化すると、失敗が発生しやすくなり、時間の浪費にもつながります。コードを細かく分割し、機能するときにチェックインするのがよいでしょう。

私の見解：開発者が自分のブランチで、または自分のサンドボックス領域で作業している場合、彼らは好きなようにチェックインできるはずです。共有ブランチ（機能ブランチ、チームのブランチ、またはもちろんMAIN /トランク）にコードをチェックインするときに、コードは可能な限り元の状態（コメント化されていないコード、FIXMEなど）である必要があります。

「ネバー」はルールが強すぎると思います。私は、コメントされたコードをリポジトリにチェックインするかどうかについて、個人的な余裕を残すために投票します。最終的な目標は、「純粋なリポジトリ」ではなく、コーダの生産性でなければなりません。

その緩やかさのバランスをとるには、コメントアウトされたコードに有効期限があることを誰もが知っていることを確認してください。コメントされたコードが1週間​​使用され、アクティブになったことがない場合は、誰でも削除できます。（「1週間」をあなたの気分に合ったものに置き換えてください。）このようにして、あなたはそれを見たときに混乱を殺す権利を留保します。

コメントアウトされたコードをリポジトリにチェックインしないでください。これがソースコード管理の目的です。

私の経験では、プログラマーがコメント化されたコードをチェックインするとき、それは彼/彼女が正しい解決策が何であるかわからず、他の誰かがその決定を下すことを期待してソースに代替の解決策を残した方が幸せだからです。

コードが複雑になり、読みにくくなっています。

ライブシステムから呼び出されない、半分完成したコード（ソース管理のメリットが得られる）をチェックインしても問題ありません。私の問題は、コードが除外されることになったジレンマが説明されていないコメント付きコードのセクションを見つけることです。

特に、コードのコメントに使用される言語タグがブロックで記述されている場合は、ソースコード管理システムでコメント付きコードをチェックインする際に、特に注意が必要です。

/* 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は通常、そこにあるべきものをテストしますが、そこにあるはずのないコードについてはテストしません。そのため、コードは、気付かないうちに本番環境で終了し、コードがそこにあるときに気付くまでに、すべきではありません。メンテナンスのコストは何倍にもなりました（「バグ」は本番環境で、または顧客によって、最悪の場所または時間で発見されるため）。

ソース管理履歴がコメントアウトするのではなく、説明と共にコメントアウトをチェックインするのではなく、何かを行う「古い方法」を説明できるようにするという考えは、理論的には良い考えです。

ただし、現実の世界では、何らかの公式なレビュープロセス（定期的にのみ行われる）の一部である場合、または何かが機能しない場合、および開発者でない限り、作業中のファイルのソース管理履歴を見ることはありません。理由がわかりません。

それでも、基本的に3つ以上のバージョンを振り返ることはありません。

部分的には、これはソース管理システムがこの種のカジュアルなレビューを簡単にできないためです。通常、古いバージョンをチェックアウトするか、古いバージョンと比較する必要があります。2つのバージョンが表示されるだけで、何が変更されたかを一目で把握できる変更点についての簡潔なビューはありません。

部分的には、それは人間の本性とチームのニーズの組み合わせです。何かを修正する必要があり、数時間でそれを修正できる場合、1か月間「ライブ」でなかった古いバージョンのコードを調査するのに1時間を費やすことはほとんどありません（各開発者が多くの場合、多くのリビジョンを戻すことを意味します）、そこに何かがあることをたまたま知っている場合（たとえば、現在行っていることに関連する何かを変更することについての議論を覚えている場合など）。

コードが削除されてチェックインされると、すべての意図と目的（完全なロールバックの限定された目的を除く）で、コードは存在しなくなります。はい、それはバックアップの目的で存在しますが、コードライブラリアンの役割を担う人物がいなければ、迷子になります。

現在のプロジェクトのソース管理ツリーは、約4名のエンジニアのチームで約10週間前のものであり、約200のコミットされた変更リストがあります。私のチームは、しっかりしていて準備ができているものがあるとすぐにチェックインする必要があるほど、良い仕事をしていないことを知っています。そのため、すべての重要な変更をキャッチするために、コードのすべての部分のコード履歴を読み取ることに依存するのはかなりおおざっぱです。

現在、初期開発モードでプロジェクトに取り組んでいます。これは、メンテナンスモードのプロジェクトとは大きく異なります。同じツールの多くが両方の環境で使用されますが、ニーズはかなり異なります。たとえば、多くの場合、何かを構築するために2人以上のエンジニアがある程度密接に連携して作業する必要があるタスクがあります（たとえば、ある種のクライアントとサーバー）。

サーバーを作成している場合、クライアントが使用するドラフトインターフェースのコードを記述し、それを完全に機能しない状態でチェックして、クライアントを作成しているエンジニアが更新できるようにします。これは、あるエンジニアから別のエンジニアにコードを送信する唯一の方法はソース管理システムを経由するというポリシーがあるためです。

タスクに十分な時間がかかる場合は、おそらく私たち2人が取り組むブランチを作成する価値があります（ただし、これは私の組織のポリシーに反しています-エンジニアと個々のチームリーダーには必要な権限がありません）ソース管理サーバー）。結局のところ、それはトレードオフです。そのため、私たちは「常に」または「決して」ポリシーをあまり導入しないようにしています。

私はおそらく、そのようなコメントされていないコードのないポリシーに少し素朴だと言って対応するでしょう。意図的であるかもしれませんが、最終的にはその目的を達成する可能性は低いです。

この投稿を見ることで、先週チェックインしたコードに戻って、コメントアウトされた部分が削除されることはありませんが（最終的には機能しましたが）、また再び望まれる可能性はほとんどありません。

コメントアウトされたコードは「無駄」だと考えられます。

あなたはチーム環境で働いていると思います。自分で作業していて、 'todo'でコードをコメントアウトすると、コードに戻ってくる場合は異なります。しかし、チーム環境では、コメントアウトされたコードがチェックインされると、そこにとどまるはずであり、満足よりも多くの苦痛を引き起こす可能性が高いと想定できます。

ピアコードレビューを行っている場合は、質問に答えることがあります。別の開発者があなたのコードをレビューし、「なぜコメントアウトされたコードが「何とか」しようとしているのはなぜですか」と言う場合、コードはコードレビューに失敗しているので、とにかくそれをチェックするべきではありません。

コメントアウトされたコードは、他の開発者に質問を投げかけるだけなので、時間とエネルギーを浪費します。

コードがコメント化されている「なぜ」という質問をする必要があります。いくつかの提案：

「ビジネスルールがわからない」ためにコードをコメントアウトしている場合は、「スコープクリープ」に問題がある可能性があります。実装する」-明確なコードと実際にそこにあるものについてのテストでそれをきれいに保ちます

「それが最善の方法であるかどうかわからない」ためにコードをコメントアウトしている場合は、コードをピアレビューしてください！時代は変わりつつあります。今日作成したコードを2年後に見て、それは恐ろしいと思います。しかし、あなたが「知っている」ことをより良く行うことができるビットをコメントアウトすることはできませんが、今のところ方法を見つけることができません。コードベースを長期間維持している人に、より良い方法があるかどうかを判断させましょう。コードを作成してテストし、機能させて、次に進むだけです。

「何かが機能しない」ためにコードをコメントアウトしている場合は、FIX IT！一般的なシナリオは、「壊れたテスト」または「todo's」です。あなたがこれらを持っているなら、あなたはそれらを修正するか、単にそれらを取り除くことによってあなたのseslfを多くの時間を節約するでしょう。一定期間「壊れる」可能性がある場合は、永久に壊れる可能性が高いです。

これらの潜在的なシナリオ（およびここで触れなかったもの）はすべて、時間と労力を浪費しています。コメントアウトされたコードは小さな問題のように見えるかもしれませんが、チーム内のより大きな問題の指標となる可能性があります。

リポジトリはコードのバックアップです。コードに取り組んでいるのに完成していない場合は、コメントアウトして、1日の終わりにチェックインしてください。そうすれば、私のハードドライブが一晩で死んでも、仕事を失うことはありません。午前中にコードをチェックアウトして、コメントを外して続行できます。

私がコメントアウトする唯一の理由は、夜間のビルドを壊したくないからです。

1）早期にチェックインすることと、2）リポジトリを常に稼働状態に維持することの間には、明らかに緊張関係があります。開発者が数人以上いる場合、1人の開発者が自分の個人的なワークフローのために他のすべての人を悩ませることはできないため、後者の方が優先順位が高くなります。つまり、最初のガイドラインの価値を過小評価しないでください。開発者はさまざまな種類のメンタルフェンスポストを使用し、個別のワークフローは、優れた開発者がこれらの余分なXを絞り出す1つの方法です。マネージャーとして、これらのすべてのニュアンス（天才であり、開発者全員が馬鹿でない限り失敗するでしょう）を理解しようとしないでください。むしろ、開発者が独自の意思決定を通じて最善を尽くせるようにします。

あなたはコメントでプライベートブランチを使用しないと述べています。あなたへの私の質問は、なぜそうではないのですか？さて、TFSについては何も知りません。ですから、理由があるのか​​もしれません。ただし、1年間gitを使用した後は、優れたDVCSがこの緊張を完全に拡散すると言わなければなりません。置換を作成しているときにコードをコメントアウトすると便利な場合がありますが、他のユーザーにコードを使用している場合は、コードをスリープ状態にしてしまいます。ローカルで分岐できることは、ダウンストリームの開発者が一時的な混乱を心配する（または通知する）必要なく、個々のプロセスに対して有意義なコミットを維持できることを意味します。

コーラスをエコーし​​ます。どんな犠牲を払ってもこれを思いとどまらせてください。それはコードを読みにくくし、現時点ではアプリケーションの一部でさえないそのコードの良し悪しを不思議に思う人を残します。リビジョンを比較することで、いつでも変更を見つけることができます。大規模な手術があり、コードがまとめてコメントアウトされている場合、開発者はチェックイン/マージの改訂ノートにそれを記録しているはずです。

不完全な/実験的なコードは、完全に開発されるブランチにある必要があります。ヘッド/トランクは、常にコンパイルされ、出荷されるメインラインである必要があります。実験的なブランチが完成したら、それを受け入れて、head / mainlineにマージする必要があります。サポートドキュメントが必要な場合は、IEEE標準（IEEE 1042）でも説明されています。

壊れている可能性があり、まだ使用されていないアクセス可能なコードが、完全に利用できない同じコードよりもチェックインされていることを確認します。すべてのバージョン管理ソフトウェアでは、トランクとは別の「作業コピー」が許可されているため、代わりにこれらの機能を使用することをお勧めします。

新しいので、機能しない新しいコードはトランクで問題ありません。それはおそらくすでに動作しているものを壊すことはありません。機能するコードが壊れた場合は、ブランチに移動するだけでよいので、他の開発者は（必要な場合）そのブランチをチェックアウトして、何が壊れているかを確認できます。

「Scar Tissue」は、私がコメント化したコードです。バージョン管理システムが広く使用される前の時代、Code Monkeysは、機能を元に戻す必要がある場合に備えて、コメント化されたコードをファイルに残していました。

「瘢痕組織」をチェックインできるのは、

1. プライベートブランチがあり、
2. エラーなしでコードをコンパイルする時間がなく、
3. あなたは長い休暇を取っています
4. Visual Source Safe ORを使用する場合のように、VCSを信頼していません。
   [編集]
5. 微妙なバグがあり、誤ったコードがリマインダーとして残されていない場合、再導入される可能性があります。（他の回答からの良い点）。

自由に利用できる堅牢なVCSシステムがたくさんあるため、＃4の言い訳はほとんどありません。Gitが最良の例です。

それ以外の場合は、VCSをアーカイブおよびコードディストリビューターにしてください。別の開発者があなたのコードを見たい場合は、彼に差分を電子メールで送って、彼が欲しいものを直接適用させてください。いずれにしても、マージは2つのファイルのコーディングがどのようにまたはどのように分岐したかを気にしません。

それがコードであるため、瘢痕組織は、よく書かれたコメントよりも気が散ることがあります。コードとしての性質上、瘢痕組織が彼の変更と関係があるかどうかを把握するために、メンテナンスプログラマーはメンタルCPUサイクルを費やします。傷跡が1週間か10歳かは関係ありません。コードに瘢痕組織を残すと、コードのあとがきを解読しなければならない人に負担がかかります。

[編集]区別する必要がある2つの主要なシナリオがあると付け加えます。

• 個人開発、個人プロジェクトのコーディングまたはプライベートブランチへのチェックイン
• チェックインされるコードが本番環境に配置されることを目的としたメンテナンス開発。

瘢痕組織に「いいえ」と言うだけです！

わからない- 変更を加える前に元の行を常にコメントアウトします-気が変わった場合に元に戻すのに役立ちます。はい、チェックインします。

ただし、以前のチェックインから古いコメントコードを削除します。

何が変更されたかを確認するためにdiffログを見ることができることは知っていますが、それは苦痛です-コードの最後の最後の変更を見るのは素晴らしいことです。

良い妥協案は、チェックアウト/変更されたファイルをネットワークバックアップドライブにダンプする小さなツールを書くことです。そうすれば、心ゆくまでコンテンツを変更して作業をバックアップできますが、実験的または未完成のコードをチェックインする必要はありません。

新しい変更がテストに合格したからといって、コメントアウトされたコードをチェックインすることは有効であるはずだと思います。

以前の変更を確認するためにいくつかのバージョンに戻る必要があり、それが現在パフォーマンスに影響を与える場合、それは非常に煩わしいでしょう。

コメントアウトされたコードは良い履歴である場合がありますが、コードがコメントアウトされた日付を入力してください。その後、コメントアウトされたコードは不要であることが判明しているため、近くで作業している人はコメントアウトされたコードを削除できます。

また、そのコードをだれがコメント化したかを知っておくとよいでしょう。そのため、何らかの根拠が必要な場合は、それらを尋ねることができます。

私は新しい機能を記述し、ユニットテストに合格し、それをチェックインして、他のユーザーに使用を許可して、動作を確認することを好みます。

まだ完成していないために開発者が一部のコードをコメントアウトしている場合、これに対処する正しい「ソース管理」の方法は、そのコードがチェックできるようになるまで、開発者が自分の別のブランチにコードを保持することです。に。

DVCS（git、bazaar、mercurialなど）を使用すると、中央リポジトリを変更する必要がないため、これは非常に簡単です。それ以外の場合は、開発者が十分な時間（つまり、数日）を要する特定の機能に取り組んでいる場合、開発者にサーバー上の独自のブランチを提供することについて話すことができます。

一部の状況では、コメント化されたコードのチェックインに問題はありません。これは、より良い方法がある可能性がある1つの状況であるため、開発者は準備ができていなくても、ソースへの変更を追跡できます。メインリポジトリにチェックインしました。

明らかに、コメントアウトされたコードをチェックインしている開発者は、別のブランチで作業し、必要に応じてトランクブランチからの変更をマージする必要があります。

このワークフローで開発者を支援するのはVCSシステム次第です（gitは、これを非常にうまく機能させる優れたVCSシステムの1つです）。