優れた/より良いソースコード管理慣行を実施する方法

私は間違った問題に焦点を合わせているのではないかと思うので、まず、私が思い描くかもしれない準最適な解決策を提示する前に、問題が何であるかを説明します。

現在の状況：
現在、私の同僚は、変更がプロジェクト全体に広がっている巨大な塊で、長い時間を経て初めてコードの変更をコミットします。かなり前のことですが、彼らはネットワーク共有に.zipアーカイブを置くだけだからです。それでも、マージは悪夢です-率直に言って、私はそれで十分でした。また、話したり説明したり、物beいをするのもうんざりです。これはやめなければならない-私なしで常に「悪者」である。

私の解決策：
問題に気づいていない、および/または問題に関心がないようであり、数日以上続く努力は期待できない...それを何時間も打って、subversionサーバーにそれをしてもらいたいしつこい。

私の質問：
私はここから離れたところにいるのでしょうか、それとも間違った問題を見ていますか？私は何かを見逃しているようで、問題を解決するツールを見ることで間違ったことを尋ねていると思います。

この問題を解決するツールを探しているべきですか、それともこれを修正するために何をすべきですか？

あなたは人間の問題に対する技術的な解決策を探しています。それはめったに機能しません。

その理由は、チームメンバーがルールを順守する代わりに何かを受け入れない（または意味を理解しない）場合、それらを回避しようとするためです。たとえば、開発者がチェッカーに強制されるのではなく、スタイルルールを受け入れて理解する必要があるのはまさにそのためです。

以下は、私が過去に使用したか、実際に実際に機会を持たずに念頭に置いたいくつかのアプローチです。チームでの地位によっては、ケースに当てはまらないものもあります（評判の良いチームリーダーである場合、学部生である場合よりも意見を実行する良い機会が得られる可能性がありますインターンシップ期間中にチームに参加しました）。

1. 同僚と問題について話し合い、大規模なコミットの結果を説明します。複雑なマージがまれなコミットの直接的な結果であることを単純に理解していない可能性があり、小規模で頻繁なコミットよりもマージが（比較的）簡単になる可能性があります。

   マージは常に複雑であると単純に確信していた多くのプログラマーを知っていました。彼らは1日に最大1回のコミットを行い、Visual Studioのdiffや自動マージなどの強力なツールの使用を避け、手動マージの実践が貧弱でした（差分検査を行わない「採掘」が実際に優れた実践でない限り）。彼らにとって、これは彼らとは何の関係もありませんでしたが、それはマージの固有の性質でした。

2. 他の会社（特に同僚が深い敬意を持っている会社）で起こっていることの具体的な例を挙げてください。彼らは単にそれが問題であることを知らず、1日に最大1回のコミットがすべてのチームが行うことだと確信しているかもしれません。

   一部の人々は、実動に最大50回プッシュする5〜10人のメンバーのチームがあることに気付いていません。これは、1人あたり1日あたり平均5〜10コミットに相当します。彼らはそれがどのように可能であるか、また誰がそれをするのかを理解していないかもしれません。

3. 例でリード。十分な小さなコミットを自分で行います。可能であれば、それらとマージを1週間にわたって並べて示す短いプレゼンテーションを行います（この種の情報をバージョン管理から簡単に抽出できるかどうかはわかりません）。マージ中に行った最終的なミスに重点を置き、実行したエラーの数（ゼロに近いはずです）と比較します。

4. 必要に応じて、「あなたに言った」テクニックを使用します。同僚が痛みを伴うマージに苦しんでいるのを見ると、小さな頻繁なコミットでマージが（比較的）痛みを伴わない可能性があると大声でコメントします。

5. コミットする最小期間がないことを説明します。コミットは、数秒で行われた小さな変更に対応することさえあります。ファイルの名前変更、古いコメントの削除、タイプミスの修正はすべて、すぐにコミットできるタスクです。

   プログラマーは小さなコミットを恐れるのではなく、多くの変更を1つの巨大なコミットに集約する必要があります。

6. 必要に応じて、チームではなく個人と作業します。頻繁に小さなコミットを特に拒否する人がいる場合は、その人と個別に話し、なぜ拒否するのかを確認してください。

   彼らは、チームで何が起こっているかについてのヒントをあなたに与えるかもしれない完全に正当な理由を与えるかもしれません。私自身が聞いたいくつかの理由：

   • 「先生/メンターは、ベストプラクティスは、1日あたりのコミット行うことであることを私に言った。」それは、私は驚かないが、与えられたものを私が大学で先生から聞いていました。

   • 「同僚は、コミットを減らすべきだと言ってくれました。」私はいくつかのチームでもそれを言われましたが、私は彼らの主張を理解しています。私たちのコミットでいっぱいになったログがありました（4人のチームメイトが1日に1回もコミットしなかった場合は難しくありません）。

   • 「小さなコミットがリビジョンを見つけるのを難しくすると思った。」チームが説明的なログメッセージを書く努力をしたとしても、どういうわけか有効なポイントです。

   • 「バージョン管理サーバーのスペースを無駄に使いたくありません。」その人は明らかに、コミットがどのように保存されているか（また、保存スペースがどれだけ安いか）を理解していません。

   • 「コミットは特定のタスクに対応すべきだと思います。」多くの場合、タスクは1日で行うべき作業（ビジュアルマネジメントのタスクボードなど）に対応するため、これは偶然ではありません。次に、バックログのタスク（2〜8時間の作業）とコミットすべき論理的に分離された変更（数秒から数時間の作業）の違いを理解する必要があります。これはポイント5にも関連しています。

7. チームがコミットを頻繁に行わない理由を検索します。結果に驚かれるかもしれません。

   最近、別の回答で、コミットの速度が重要であり、数百ミリ秒でさえも開発者がコミットする頻度を減らす可能性があると述べました。

   その他の理由は次のとおりです。

   • コミットメッセージを記述するための非常に複雑なルール。

   • 開発者にコミットをバグ追跡システムからのタスクにリンクさせるルール。

   • ビルドを壊す恐れ。

   • 今すぐビルドを壊すリスクに対処したくない：去る直前に金曜日の夕方にコミットする場合、壊れたビルドの処理を月曜日まで延期できます。

   • マージを行うことへの恐怖。

8. 頻繁にコミットする他の利点があることを開発者が理解しているかどうかを判断します。たとえば、継続的インテグレーションプラットフォームは、リグレッションが導入された場所を正確に特定できるため、頻繁なコミットを行う大きな動機となります。

   私は、CIプラットフォームで、50分前に行った1つのファイルの2つのメソッドの変更で構成されるリビジョン5023でビルドを中断したことを伝えます。 13時間の仕事。

私が過去に契約した組織は、この同じ問題を解決したいと考え、かなり良い社会的ソリューションを思いつきました。開発者は自分のコンピューターを持っていません。開発チームにはコンピューターがありますが、任意の個人が任意の日に開発コンピューターで作業するように求められ、期待されます。したがって、チェックインは、昨日行っていた作業を続行できることを確認する唯一の方法です。

その後、経営陣は回って、数時間後にコンピューターの変更を密かに元に戻したため、チェックインされていないものはすべて失われました。これらの「シミュレートされたコンピューター障害」は、開発者が乗る前に数回発生するだけでした。

もちろん、ルールの「理由」と「何」を説明することは重要です。「理由」を明確にしない限り、彼らはUSBドライブなどにソースを保存することができます。