どのようにして良い/より良いソースコード管理を実施するのですか？
私は間違った問題に焦点を合わせているのではないかと思うので、私が想像する最適ではない可能性のあるソリューションを提示する前に、問題が何であるかを最初に説明します。
現在の状況：
現在、私の同僚は、変更がプロジェクト全体に広がっている巨大なチャンクで長い期間を経た後にのみ、コードの変更をコミットします。少し前まで、.Zipアーカイブをいくつかのネットワーク共有に配置しただけなので、それは私が推測する進歩です。それでも、マージは悪夢です-そして率直に言って、私は十分にそれを持っています。そして、私はまた、話したり、説明したり、物乞いをすることにうんざりしています。これは停止する必要があります-私が常に「悪者」になることはありません。
私の解決策：
問題に対する認識や関心がないようで、数日以上続く努力は期待できないので...それを何時間もかけて、Subversionサーバーにしつこいことをする。
私の質問：
私はここからかなり外れていますか、それとも間違った問題を見ていますか？何かが足りないようですが、問題を解決するためのツールを調べて間違ったことを尋ねていると思います。
この問題を解決するためのツールを探しているのでしょうか、これを修正するにはどうすればよいですか？
あなたは人間の問題に対する技術的な解決策を探しています。それはめったに機能しません。
その理由は、チームメンバーがルールを順守する代わりに、何かを受け入れない（またはその影響を理解しない）場合、それらを回避しようとするためです。 それがまさに、たとえば、開発者がチェッカーによる強制を強制されるのではなく、スタイルルールを受け入れて理解する必要がある理由です。
以下は、私が過去に使用した、または実際にそれらに機会を与えることなく心に留めたいくつかのアプローチです。チームでの立場によっては、ケースに当てはまらない場合があります（優れた評判のチームリーダーの場合、学部生よりも見解を執行する機会が増える可能性があります。インターンシップの期間中、チームに参加しただけです）。
同僚と問題について話し合い、大きなコミットの結果を説明します。複雑なマージがまれなコミットの直接の結果であることを単に理解していないのかもしれません。小さく、頻繁にコミットすることで、マージが（比較的）簡単になります。
マージは常に複雑であると単純に確信している多くのプログラマーを知っていました。彼らは1日に最大1回のコミットを行い、Visual Studioのdiffや自動マージなどの強力なツールの使用を避け、手動マージの習慣が不十分でした（これ以上diff検査を行わない「採掘」が実際に良い方法でない限り）。彼らにとって、これはthemとは何の関係もなく、マージの本質的な性質でした。
他の会社で起こっていることの具体例を示してください（特にあなたの同僚が深く尊敬している会社）。彼らは単にそれが問題であることを認識しておらず、1日あたり最大1つのコミットがすべてのチームが行うことであると確信しているかもしれません。
一部の人々は、本番環境に最大50回のプッシュを行う5〜10人のメンバーのチームがあることを知らないため、1人あたり1日あたり平均5〜10回のコミットになります。彼らはそれがどのようにして可能であるのか、なぜ誰もがそれをするのか理解していないかもしれません。
例によって主導。十分な小さなコミットを自分で行う。可能であれば、1週間にわたってそれらとマージを並べて表示する短いプレゼンテーションを行ってください（この種の情報をバージョン管理から簡単に抽出できるかどうかはわかりません）。マージ中に彼らが行った最終的な間違いを強調し、それをあなたがやったエラーの数と比較します（ゼロに近いはずです）。
「私が教えた」テクニックを使用する必要に応じて.同僚が苦痛なマージに苦しんでいるのを見かけたら、小さくて頻繁にコミットはマージを（比較的）簡単にすることができます。
コミットを実行するための最小期間がないことを説明します。コミットは、数秒で行われた小さな変更にも対応する場合があります。ファイルの名前の変更、古いコメントの削除、タイプミスの修正は、すぐにコミットできるすべてのタスクです。
プログラマーは小さなコミットを恐れず、多くの変更を1つの大きなコミットに集約する必要があります。
必要に応じて、チームではなく個人と協力してください。頻繁に小さなコミットを行うことを特に拒否する人がいる場合は、その人と個別に話して、なぜ彼が拒否したのかを確認してください。
彼らはあなたにチームで何が起こっているかについてのヒントを与えるかもしれない完全に正当な理由を与えるかもしれません。私が自分で聞いたいくつかの理由：
「私の教師/メンターは、ベストプラクティスは1日に1回コミットすることだと私に言いました。」それは私を驚かせません 与えられた何私は大学の先生から連絡をとらなければなりませんでした 。
「私の同僚は私がコミットを少なくすべきだと私に言った。」一部のチームでもそうだと言われ、彼らのポイントを理解しています。私たちのコミットで実質的に満たされたログがあり（4人のチームメイトが1日に1回のコミットさえしない場合でも、それほど難しくはありません）、同僚を苛立たせました。
「小さなコミットはリビジョンを見つけるのを難しくすると思っていました。」チームが説明的なログメッセージの作成に力を注いだとしても、何となく妥当なポイントです。
「バージョン管理サーバーのスペースを無駄に使いたくない」その人は、コミットがどのように保存されるか（また、ストレージスペースがどれほど安いか）を理解していません。
「コミットは特定のタスクに対応するべきだと思います。」多くの場合、タスクは1日で実行されるいくつかの作業に対応します（視覚管理のタスクボードなど）、これは偶然ではありません。担当者は、バックログのタスク（2〜8時間の作業）と、コミットする必要のある論理的に分離された変更（数秒から数時間の作業）の違いを理解する必要があります。これは、ポイント5にも関連しています。
チームがコミットを頻繁に行っていない理由を検索します。結果に驚くかもしれません。
最近、私は 別の答えで コミットの速度が重要であることを述べました 数百ミリ秒でも 開発者に、より少ない頻度でコミットするようにプッシュするかもしれません。
その他の理由には次のものがあります。
コミットメッセージを書くための過度に複雑なルール。
開発者にバグ追跡システムからのタスクへのコミットをリンクさせるルール。
ビルドを壊す恐れ。
ビルドを壊すリスクに今すぐ対処したくない場合：金曜日の夜に去る直前にコミットすると、壊れたビルドへの対処を月曜日まで延期できます。
合併を行うことへの恐怖。
開発者が頻繁にコミットする他の利点があることを理解しているかどうかを判断します。たとえば、a継続的インテグレーションプラットフォームは、頻繁にコミットすることへの大きなインセンティブです。これにより、回帰が導入された場所を正確にピンポイントできるようになります。
CIプラットフォームが、4ダースのファイルにまたがって表す変更で構成されるリビジョン5023ではなく、15分前に行った1つのファイルでの2つのメソッドの変更で構成されるリビジョン5023でビルドを中断したことを伝える方がいいと思います13時間の作業。