回答:
私が習慣にしていることの1つは、チェックインする直前に、チェックインしようとしているすべてのファイルの差分を常に確認することです。
コメントアウトされたコードをチェックインしないでください。チェックインする前にコメントアウトする必要があるコードがある場合、それは間違っています。
ルールに関して：
構築する
3.1ビルドエラーを修正
テストを実行する
4.1壊れたテストを修正する
1に移動します（取得する新しいものがなくなるまで）
すべてのステップが完了したときにのみチェックインしてください。
その他の良い習慣：
rebase -iは、必要に応じてローカルでコミットできます。その後、メインリポジトリにプッシュする前に、必要に応じてコミットを破棄し、ローカルヒストリをクリーンアップします。
などTFS、SVN、PERFORCEの、として、私はあまりここpantsweaselのことをしようとしないんだけど、この問題の仮定は（とすべてが、答えの1）ほとんどの集中VCSに適用される
フェア十分にはそれが何です、 OPが使用しています。
一方、DVCS（MercurialやGitなど）を使用する場合は、通常、チェックインを待つ必要はありません。また、回答に記載されているもの（diff、最新版、マージなど）のほとんどは不要です。 。コードレビューやテストなどのことでも、チェックイン後に行う方が良いでしょう（ただし、プッシュする前に依存する可能性がありますが...）
ここで見た1つの例外は（これまで）ワークアイテムとの関連付けです。もちろん、チェックインについてコメントすることも良いです...
他の答えには見られなかった3つのこと：
新しいファイルを含める
変更されていないファイルを元に戻す
送信したコミットを確認する
Gitを使用するときの2つのこと：
アトミックコミット：
git add --patch、必要に応じて複数の部分に私の変更を分割します。要約しながら差分を表示
git commit --verboseので、コミットメッセージを入力している間に変更の差分を見ることができます。（または、パッチを適用したgit-vimを使用して差分を表示します。）私のチームのサーバーに適用する「良い習慣」のいくつかの項目は非常に簡単です。まず、チェックインする前に、常に最新のものを取得してローカルビルドを実行し、コード内で他の誰もチェックしていないことを確認する必要があります。さらに、サーバーではなく、ローカルマシン上のコードの競合に注意してください。最新のコードがダウンロードされたコードが適切にビルドおよび動作することが確認されたら、次のステップに進む準備ができています。自動化されたテストを実行し、チェックインを開始して、引き続き正常に機能することを確認します。その後、念のため、もう一度最新情報を入手してください。
TFS管理者として、すべてのチェックインにコメントを強制することができます。強制されているかどうかに関係なく、常にチェックインコメントを入力することをお勧めします。そうするオプションがある場合は、強制します。コメントは、少なくとも、最後にコードをチェックインしてから変更した内容の一般的な要約であることを確認してください。そうすれば、何か問題が発生した場合は、チェックインを調べて、おおよその内容を確認できますそのチェックインで変更されました。壊れたビルドのデバッグがずっと簡単になります。
さらに、TFS管理者権限がある場合は、チェックインでローリングビルドを強制し（チェックインが何かを中断した場合に他の人がすぐにわかるように）、ゲートチェックインを実行するようにサーバーを設定できます（チェックインされたコードがビルドを壊した場合、サーバーはそれを拒否します）、または単にバグを作成し、ビルドを壊した人にそれを割り当てることができます。
すべてを適切に保つためにオンまたはオフにすることができる他のオプションがいくつかあります。
Windowsからチェックインする場合、コードにこれらの目に見えない^ M文字がないかどうかを確認してください-UNIXのエディターは、そのためにエラー/警告を出すことがよくあります。
また、タブを試してみてください-異なるユーザーは、4つのスペース、8つのコード、およびコードの可読性が良くないタブストップを別の方法で見ることになります。
私見の最善のアプローチは、事前に定義されたスクリプトに、組織のコーディングガイドラインに対してコードをチェックさせることです。ソース管理システムの負荷にはこの機能があります。
可能な限り、チェックインをワークアイテムに関連付けたいと思っています。これにより、変更された理由だけでなく、変更された理由に関するコンテキスト情報が得られます。TFSにはかなりまともな作業項目追跡システムがあるため、チェックイン時にこれを行うのはかなり簡単です。
（これは私の変更の差分を確認することに加えて）
ここですべての回答を組み合わせて、完全なチェックリストを提供するには
[チェックイン/チェックアウト]他の人が作業しているストリームに直接チェックインしないでください。例えば、開発者ごとに、他の人を煩わせることなく独立してチェックインおよびチェックアウトできるストリームを作成する必要があります。安全であるが、あなた自身の開発ストリームにあるので[あなた自身の開発ストリームにのみ]。チェックインのたびに、変更セットと呼ばれるその変更に対して変更がアトミックになるように変更レコードに関連付けます（したがって、「すべて」を配信することなく、個々のrfcやバグなどを配布できます）。
[そして、あなたのチームストリームでリベースします]これは、自分のストリームで他の人から変更を取得することを意味します。その操作中に、マージダイアログですべての「差分」を確認し、それらを通過することができます...または数千がある場合、および/またはコードではなくデータモデル/ Siebelプロジェクトなどを使用している場合...非自明なマージ、自明な自動マージおよび自明な手動マージ、最後のカテゴリには難しいものが含まれます。まだ自分のストリームで作業していることに注意してください。
[完全なリベース]すべてが問題なければ、チームストリームから取得したすべての変更をチェックインします。あなた自身のストリームは最新です
[配信]は、チームストリームに作業を配信します。すべてを配信したくない場合は、たとえば、特定のバージョンのファイルを含む1つの特定のRFC、または解決済みのRFC /欠陥のセットを選択することもできます。
[テスト配信]は問題ありませんが、誰かが変更を配信する可能性があるため、チームストリームの最新の変更で作業が機能するかどうかをテストできます。違いを示す同じマージダイアログを使用します。
[完全な配信]配信を完了すると、作業はチームストリームに追加されます。
より複雑にするために：提供した作業がまだ可能性があるため、別のバージョンで作業している可能性がありますが、提供後に常にベースラインを設定し、他のユーザーがリベースするのに好ましいベースラインを指定する必要があります。これにより、他の開発者がストリームの最新バージョンではなく推奨バージョンを取得することが保証されます（そのシナリオで作業している場合）。これはトリプルチェックでもあるため、チームストリームの最新バージョンが「悪い」場合でも、他のユーザーがリベースまたは参照するバージョンではなく、構成マネージャーは前のバージョンを次のバージョンにマージして元に戻すことができますあなたの配達。
あなたの例では、コードをコメントアウトするのを忘れたことを伝えます。間違いが起こります。その周りの構成管理システムがそれを処理する必要があります。たとえば、数千の変更が発生し、「ビルド」と「統合」が異なるサーバー上のストリームの階層で発生し、時間の経過とともに処理されます。したがって、5か月後にコメントアウトされたコードが統合サーバーでテストされたとしても、コードは他のコードやシステムとの統合を必要とするため、変更セットをアトミックに取り出して継続することが可能です。そのため、ベストプラクティスは多かれ少なかれ高いレベルで行われます。構成管理ストリームの全体的な設計がそれを処理する必要があります。個々の開発者にとってのベストプラクティスは、もちろん検証/単体テストです。しかし、全体像から「
以下のいくつかは、SCMに応じて他の（または異なる形式で）適用されるため、ここで説明します。
注：項目のいくつかは、上記のかなり明白に見えるが、あなたは最初の生産上のメインブランチやメイクの変化にどのように多くの人々 、実際に仕事を信じていないでしょうし、その後、手動で直接、メインブランチに...バージョン管理に行くためにデルタを作成します。 ..およびラベル付き。発酵させた胆汁のような甘いものに、洗っていない脇の下のジュースを混ぜて…ええ、そのように。
個人用のチェックリストを用意してください。入り口で台無しになったら空にしてください。第二の性質になったら、リストから削除します。
テストを実行します。合格した場合はチェックインします。混乱してテストを通過した場合は、テストを作成します。
私たちは次のことを行います...
テスト-動作することを確認したい。少なくとも、それが何も壊さないことを知りたいです。
コードレビュー、または少なくともバディチェック-これは、知識が広まり、人々が最新の状態に保たれることを保証する素晴らしい方法です。また、チェックインする前にバグをキャッチするのにも役立ちます。
事前通知の送信-チェックイン前に事前通知がグループに送信されます。目的は、どのファイルまたは領域が変更されているかを他の人に知らせることだけでなく、それらの変更がそれらに影響を与えると予想される場合に注意を促します。
事前通知を送信してから数時間後、チェックインが実行され、グループにメールで通知されます。グループの全員が、バグまたは機能に関する特定の作業がいつ完了したかを知ることができます。
チェックイン通知のコピーは、バグまたは機能に関連付けられた修正レコードに貼り付けられます。レコードを検索するとき、修正/機能が何を伴うのかを知ることが非常に便利であることがわかります。
スタンドアロンユニットとして使用できる変更の部分を探します。
多くの場合、コードの作業修正または機能拡張を行うまでに、かなりの数の変更があります。それらのいくつかは、私がしようとしている行動の変化に固有のものです。他のものは、私がその変更をよりきれいにするためにしたリファクタリングです。
次のように、独自の変更記述を使用して、各リファクタリングを個別にチェックインすることを好みます。
REFACTORING：Xの名前をYに変更
Xは以前は理にかなっていましたが、今ではYになっているはずです。これは、問題＃9の作業に関連しています。
その後、適切なリファクタリングがそれぞれチェックインされると、最終的な動作の変更はたいてい些細なことです。
また、一部の変更は多くのコード行に影響を及ぼしますが、あまり面白くありませんが、他の変更は非常にローカライズされていますが、重要な影響があります。これらの変更を一緒にチェックインすると、差分を読みにくくなる可能性があります。だから、私はそれらを別々に保ちます。
後に、誰かが変更履歴を読んでいるとき、物事が現在の状況にどのようになったか、そしてなぜそうなっているのかは明らかです。また、他の多くの編集と絡み合っていないため、動作の変更を元に戻すのも簡単です。
あなたが誰かから借りたものを返すときにあなたがすることをしてください。きれいで、形が整っていることを確認してください。混乱した場合は、コードを所有者（ほとんどの場合、雇用主）に返す前に必ずクリーンアップしてください。