私はSVNから始めています。基本的なコマンドを理解し、基本原則を理解しています。チーム環境でSubversionを使用するためのヒントやベストプラクティスがあるかどうか疑問に思っていました。
コードをコミットするときにかなり詳細なメッセージを追加することのメリットはわかりますが、他に注意すべき点はありますか？
すばらしい回答をありがとう-彼らはたくさん助けてくれました。
私はSVNから始めています。基本的なコマンドを理解し、基本原則を理解しています。チーム環境でSubversionを使用するためのヒントやベストプラクティスがあるかどうか疑問に思っていました。
コードをコミットするときにかなり詳細なメッセージを追加することのメリットはわかりますが、他に注意すべき点はありますか？
すばらしい回答をありがとう-彼らはたくさん助けてくれました。
回答:
頻繁なコミットを奨励します。 バージョン管理に不慣れなチームメイトは、「正しく機能する」まで、コードをリポジトリから除外する必要があるように感じるかもしれません。できるだけ早く、頻繁に問題を見つけるようにコミットするように全員に教えます。機能するまでコードを保持する代わりに、チームメイトがトランクを壊す可能性のある機能のブランチを作成することを提案します。それは...につながります
分岐とタグ付けのプラクティスを確立します。 機能のブランチに加えて、チームメイトにブランチを使用して大きなバグを修正するように促します。作業の始めと終わりに主要なバグ修正にタグを付けます。プロダクション/ QAリリースのタグ（および場合によってはブランチ）を維持します。
トランクのポリシーを確立し、それに固執します。 たとえば、「トランクは常にエラーなしで構築する必要があります。」または「トランクは常にすべての単体テストに合格する必要があります」。トランクの基準をまだ満たしていない作業は、ブランチで行う必要があります。
コードの変更に伴うフォーマットの変更をコミットしない
巨大なファイルの空白（Control+ K+ D）を再構築する場合は、問題ありません。フォーマットの変更は、実際の論理的な変更とは別にコミットします。ファイル内で関数を移動したい場合も同様です。実際の編集とは別に移動をコミットします。
私が常に固執する主要な概念の1つは、関連するコードの変更をまとめてコミットすることです。その結果、同じコミットで無関係なコードの変更をコミットしないでください。つまり、1つのコミットで2つのバグを修正しないでください（同じ修正でない限り）。また、2つのコミットのそれぞれでバグ修正の半分をコミットしないでください。また、システムの無関係な部分に新しい拡張機能や何かを追加する必要がある場合に、他の作業に必要な場合は、拡張機能を個別に（最初に）コミットします。このアイデアは、だれかが単独で行いたい（または自分でロールバックしたい）と思われる変更は、個別のコミットであるということです。マージや壊れた機能をロールバックするときに、頭痛の種を大幅に節約できます。
多くのことはすでに述べられており、ここにいくつかあります：
ソース管理に必要のないファイル（構成、コンパイル済みファイルなど）がある場合は、それらを無視リストに追加します。このように、SVNに不明として表示されるファイルの空のリストを常に期待することで、追加を忘れたファイルに気づきます。
コミットされた変更と理想的にはそのパッチに関する開発者メーリングリスト（またはこのターゲットに固有のメーリングリスト）にメールを送信するコミット後イベントを追加します。
バグトラッカーと統合して、コミットへの参照がバグ/機能リクエストに差分へのリンクとともに表示されるようにします。MantisBTのようなバグトラッカーはこれをサポートしています。
継続的インテグレーション（CruiseControl.NETなど）、ビルドにはNAnt、ユニットテストにはNUnit / VS との統合を検討してください。このようにして、ユーザーがコードをチェックインするか、スケジュールされた間隔でコードがコンパイルされると、単体テストが実行され、開発者はプロセスのフィードバックを取得します。これは、リポジトリが壊れている（つまり、ビルドされない）場合に、チームの他のメンバーに警告することにもなります。
まあ、基本：
人々の答えは素晴らしいです。これの多くは、SVNのベストプラクティスについて svn user docに要約されています。
繰り返す：
私が守っているベストプラクティスをまとめたいと思います。
リポジトリ構造が必要です。個人的に私は次のリポジトリ構造を使用しています：
/trunk
/tags
/builds
/PA
/A
/B
/releases
/AR
/BR
/RC
/ST
/branches
/experimental
/maintenance
/versions
/platforms
/releases
PAプレアルファ）、A（アルファ）、B（ベータ）、AR（アルファリリース）、BR（ベータリリース）、RC（リリース候補）、ST（安定版）。私のsubversionのベストプラクティスの概要は、私が使用するソフトウェア構成管理アプローチの主な原理を示す図の形で見つけることができます。
私が非常に便利だと思ったのは、svn：externalプロパティです。これは、他のリポジトリから独自のリポジトリにディレクトリを参照できることを意味します。それはあなたのコードとデータを整理する本当に素晴らしい方法を提供します。次に例を示します。
バグ追跡ソフトウェアとの統合を使用します。Bugzillaを使用している場合は、それを設定して、コメントが「Bug XXXX」で始まる場合、SVNコメントが、そのリビジョンへのSVN Webインターフェースへのリンクを含む、所定のバグへのコメントとして自動的に追加されます。
SVNの分岐およびマージツールと規則について学びます。
他のチームメンバーと作業するための最良の方法は、作業を完全な開発機能/修正に分割し、ブランチごとに個別の変更に取り組むことです。次に、変更がマージされて、完了した/準備ができた/マージすることが承認されたときにメインラインのブランチ/トランクにマージします。
このようにして、個人は他の変更と衝突することなく、（同じブランチまたは別のブランチのいずれかで）共通の目標に向かって作業できます。
あなたの走行距離は異なる場合があり、これはたった2人ほどの人にとっては行き過ぎかもしれません。
SVNとうまく統合できる優れたツールを使用している場合は、はるかに簡単になります。これらにより、変更内容を簡単に確認し、変更のすべてまたは一部をコミットし、作業コピーをSVNの最新バージョンに頻繁に更新できます。
私はお勧めトータスSVN（Windowsを使用している場合）とビジュアルSVN（あなたがVSを使用している場合）を。
また、変更がコミットされるたびに電子メールまたは同様の通知を受け取るように設定できるかどうかを確認します（通常は、コミットメッセージと変更されたファイルのリストも含まれます）。CVSDudeのようなサービスがこれを提供します。更新が行われたことを知ってから、作業コピーを更新する前に、その更新に何が含まれているかを理解しておくと役に立ちます。
分岐ポリシーなどに加えて。（1つのサイズですべてに対応できるわけではありません）、適切なコミットが必要です。
ソース管理の黄金律：早期チェックイン、頻繁チェックイン
リポジトリを整理するためのヒント：
マージの競合を修正する前に、変更についてチームに相談するか、少なくとも差分を注意深く確認してください。マージされたコードをレビューして、追加がマージで失われていないことを確認するよう依頼してください。
壊れたコミットを減らすことがわかったのは、適切なプリコミットスクリプトを用意することです。たとえば、変更がコミットされる前に任意の単体テストを実行できます。これにより、コミットが少し遅くなりますが、誰かのつま先を踏んだり、謝罪したりする必要がないため、時間を節約できます。もちろん、大規模な開発チームと非常に頻繁なコミットがある場合、これを管理するのは非常に難しくなります。
SVNを使用するためのベストプラクティス：
最初にオフィスに来てEclipseプロジェクトを開いたとき、最初のステップはプロジェクトを更新することです。
更新後、作業を開始します。コーディングが終了したら、それを適切にチェックし、アプリケーションが例外なく適切に実行されるかどうかを確認します。コードが正常に機能していることを確認したら、コードをコミットします。
注：コードをコミットするときは、直接コミットしないでください。サーバーと同期し、コミットする必要があるものをすべて確認します。注：フォルダ全体を一度にコミットしないでください。要件に応じてファイルにいくつかの変更を加えたか、ローカルシステムの一部のファイルを削除した可能性があるためです。ただし、サーバーでは設定が異なります。したがって、ファイルを個別にチェックして、コードをコミットします。
競合ファイルを直接コミット/更新しないでください。
いつオーバーライドして更新するのですか？
ローカルでの変更が不要で、サーバーコピーを完全に更新したい場合。上書きして更新すると、ローカルの変更が反映されなくなることに注意してください。
注：1日以上更新せずにプロジェクトを維持しないでください。また、何日もコミットせずにコードを保持しないでください。
全員が同じコンポーネントで作業していることを伝え、彼らが毎日行った変更について話し合います。
何らかの理由がない限り、プロパティと構成ファイルをコミットしないでください。サーバーとクラウドでは設定が異なるためです。
ターゲットフォルダをSVNにコミットしないでください。SVNリポジトリで維持する必要があるのは、ソースコードとリソースフォルダのみです。
コードを紛失しても、慌てる必要はありません。SVN履歴から以前のコピーを取り戻すことができます。
プロジェクトをディスクの複数の場所にチェックアウトしないでください。1か所でチェックアウトして作業します。
SVN自体は良い出発点であり、他のポスターのいくつかは、ベストプラクティスに関するいくつかの素晴らしい提案を提供しています。
私が追加する唯一のことは、継続的インテグレーションプロセスを推進するためにCruiseControlまたはTeamCityでSVNを接続する必要があるということです。これにより、ビルドのメールが送信され、誰かがビルドを壊したときに全員に通知されます。
それはあなたのプロセスをフォローしている人とフォローしていない人の早い段階で非常に分かります。多少の摩擦につながる可能性がありますが、あなたのチームは長期的にはうまくいくでしょう。
コミットごとの正確なコメント
（メインライン）ビルドを壊さないでください！
論理ユニットが変更されるとすぐにコミットする
バックアップツールとしてSubversionを使用しない
少しの分岐/マージ
。
詳細については、SVNのベストプラクティスをご覧ください。
増分、モジュール化、個別化、簡潔化してコミットを行うほど、あなた（または他の可能性のある人）が次のことを簡単に行えるようになります。