従来のチームに分散バージョン管理を使用する頭痛の種

私は個人的なプロジェクトにDVCSを使用しており、他の人からプロジェクトへの貢献を管理するのが簡単になることを完全に見ることができますが（たとえば、典型的なGithubシナリオ）、「伝統的な」チームにはいくつかの問題があるようですTFS、Perforceなどのソリューションで採用されている集中型アプローチ（「従来」とは、誰もが同じコードに触れる可能性のある、誰も「所有しない」1つのプロジェクトに取り組んでいるオフィスの開発者チームを意味します。）

これらの問題のいくつかは私が自分で予見しましたが、他の考慮事項でチャイムしてください。

従来のシステムでは、サーバーに変更をチェックインしようとすると、競合する変更を他の誰かが以前にチェックインした場合、チェックインする前にマージを強制されます。DVCSモデルでは、各開発者がローカルで変更され、ある時点で他のリポジトリにプッシュされます。そのリポジトリには、そのファイルのブランチがあり、2人が変更しました。今、誰かがその状況に対処する責任を負わなければならないようです。チームの指定された人は、すべての競合のマージを処理するためにコードベース全体の十分な知識を持っていない場合があります。したがって、誰かがそれらの開発者の1人にアプローチし、プルしてマージを実行してから再度プッシュするように指示する（または、そのタスクを自動化するインフラストラクチャを構築する）必要がある追加のステップが追加されました。

さらに、DVCSはローカルでの作業を非常に便利にする傾向があるため、開発者がプッシュする前にローカルリポジトリにいくつかの変更を蓄積して、こうした競合をより一般的で複雑にする可能性があります。

チームの全員がコードの異なる領域でのみ作業する場合、これは問題ではありません。しかし、私は誰もが同じコードで作業している場合に興味があります。一元化されたモデルは、競合を迅速かつ頻繁に処理することを余儀なくし、大規模で痛みを伴うマージを行う必要性を最小限に抑えるか、誰かにメインリポジトリを「ポリシング」させるようです。

あなたのオフィスであなたのチームとDVCSを使用している人のために、あなたはそのような場合にどのように対処しますか？毎日の（またはより頻繁に、毎週の）ワークフローが悪影響を受けていると思いますか？職場でDVCSを推奨する前に注意すべきその他の考慮事項はありますか？

Mercurialを約1年間使用しています。あなたが言及した頭痛の種は存在しますが、私たちにとって完全に採用するための最大の課題は、ローカルリポジトリのDVCSの考え方（=頻繁にコミットすること）に入ることでした。行く。

あなたが言った：

DVCSモデルでは、各開発者はローカルで変更をチェックインし、ある時点で他のリポジトリにプッシュします。そのリポジトリには、そのファイルのブランチがあり、2人が変更しました。今、誰かがその状況に対処する責任を負わなければならないようです。

Mercurialのデフォルトインストールは、この動作をブロックします。リモートリポジトリで複数のヘッドが追加の確認なしで作成される場合、プッシュは許可されません。毎日の活動では、それを避けます。（Gitには名前付きヘッドがあり、それぞれが以前のバージョンを完全にマージする場合にのみ追加の確認なしで更新できるため、状況が再び発生することはありません。他のDVCSにも同様の保護があります。）

そのため、各営業日の終わりに、コミットのための時間を確保する必要があります。これは実際には次のアクティビティです。

1. ローカルの変更をコミットします。
2. 中央レポから引き出します。
3. マージ（＆マージをコミット）
4. 中央レポにプッシュします。

これにより、最近このコードで作業していた人のマージアクティビティが維持され、他の人と同じくらい迅速に変更を統合できるはずです。

質問で指摘したように、これは実際には2人が同じコード領域で作業している場合にのみ労力を追加します。その場合は、とにかくDVCSを使用することでより多くの利点が得られるため、これらの開発者にとっては見返りはすでに明らかです。（追加の利点には、各開発者がコードを個別にコミットし、他の開発者が邪魔されることなく独自のレポで遊ぶことができることが含まれます。）

あなたが言及する別の問題：

さらに、DVCSはローカルでの作業を非常に便利にする傾向があるため、開発者がプッシュする前にローカルリポジトリにいくつかの変更を蓄積して、こうした競合をより一般的で複雑にする可能性があります。

これにより、マージの問題は発生しませんが、別の問題が発生する可能性があります。

DVCSの柔軟性は、多くの異なるワークフローが可能であることを意味しますが、それらの一部は無責任です。DVCSを使用すると、明確なプロセスまたは手順の必要性が高まります。ローカルの変更を保持するアクティビティは、多くのことに応じて適切な場合と適切でない場合があります。

たとえば、開発者は数週間にわたって空き時間にペットの機能を操作できますか？一部の環境ではこれが推奨され、一部の環境では不適切であり、すべての変更をすぐに集中化する必要があります。しかし、開発者が変更をローカルに保持している場合、関連する変更をプルして、作業が最新の共通のリビジョンで引き続き適切に再生されるようにする必要があります。

ゴムが道に出会うと、ソフトウェアのリリースまたは展開は通常中央レポジトリから行われるため、開発者はテストと展開のためにそこで変更を取得する必要があります。

それが私の話であり、少なくとも数分間はそれにこだわっています...

あなたの質問の前提は、「マージは難しく、避けなければならない」ということです。DVCSシステムは、この障壁を取り除きます。実際、より多くのことを行い、マージの概念を受け入れます。結果として、マージとマージの競合を恐れてはいけません。集中型ツールとは異なり、DVCSツールは設計によってサポートします。

Jamie Fの優れた答えとして、定期的に（毎日）行われるCommit-Pull-Merge-Pushのワークフローは、他の作業を歩いている場合、早期に表示されることを意味します-表示されている限り、管理できます。

説明する問題は、ツールの使用方法に関するものです。

SVNとGITを数年間ローカルで使用した後、6か月前にSVNからGITに切り替えました。誰も戻ってこないだろうし、痛みを伴うマージ競合は過去のものだ。「小さくて頻繁にコミットする」というマントラが重要です。

私がgitを使用するチームで働いていたときの経験則は次のとおりでした：プライベートブランチで作業し、チームの他のメンバーが作業を利用できるようになったら、プッシュする前にブランチをマスターにリベースします。（その後、ブランチを検証します。）

この戦略は、マスターがコミットの線形シリーズであり、すべての統合の問題が公開される前にブランチで修復されたことを意味しました。

SVNのようなツールは、密接に統合された作業方法を強く推奨します。

つまり、共有ブランチ（トランクまたは開発ブランチ）に頻繁にコミットします。

これは私が経験したほとんどの企業開発環境にとっては大丈夫であり、広範な統合テスト、回帰テスト、単体テストでサポートされる継続的統合を使用することで、さらに促進および促進されますその変更によるもの）。

DVCSを使用すると、状況に応じて必要な独立した作業を自由に行うことができます。また、（非常に有名な）マージの改善されたサポートは、まったく害を及ぼすことはありません。

常に私の心の奥に残る心配はこれです。大きな自由があれば、その自由を使う誘惑が生じます。

確かに、私の（限られた）経験では、以前の役割（SVN、CVS、P4を使用した）で行っていた時間よりも、現在のチームで（Mercurialを使用して）独立して作業することに多くの時間を費やしています。

これはツールに部分的に起因するだけですが、それを行うのは合理的な観察であり、コミュニケーションと調整に努力を費やす説得力のある理由がなければ、人々は離れて孤立して働く傾向があると思います。

これは必ずしも悪いことではありませんが、考慮する必要があると思います。

git / mercurialタイプのバージョン管理で重要なことは、頻繁にコミットし、コードが適切なときに集中サーバーにプッシュすることです。これの大きな利点の1つは、競合の場合に簡単に適用できる小さなパッチを作成することです。また、ワークフローは次のようなものでなければなりません。

1. 多くのローカルコミット
2. サーバーからプル
3. サーバーにプッシュ

このサーバーからのプルにより競合が発生する可能性がありますが、これを解決するために必要なのは、マージではなく単純なリベースだけです。これは、メインラインの履歴を非常にきれいに保ち、非常に多くの競合を取り除きます。

これは、2つのことが起こる可能性があるため、同僚のローカルリポジトリからプルする場合にも当てはまります。彼は最初にサーバーにプッシュしますが、これは既にパッチを持っているので問題ありません。競合を起こさないか、最初にプッシュします。

もちろん、マスターにマージする機能ブランチで作業している場合の例として、マージがより良いソリューションである場合があります。

ワークフローでは、他の開発者に明示的にアクセスし、競合を修正するように指示する必要があることについて話しますが、それは必要ではありません。中央サーバーは「ボス」であり、主に対処すべきものです。変更が中央レポに適用される場合、OKです。そうでない場合、競合を修正するのはあなたの仕事です。そのため、競合する開発者が自分の変更を理解するのに役立つ場合があります。これは、サーバーからプル/リベースしようとしたときに表示されるものです。したがって、コミットして満足し、サーバーからプルする必要があるときに競合に対処してください。

集中リポジトリを操作する原理は、非ロック集中システムまたは分散システムを操作する場合と同じです。

• 集中システムでは、次のことを行います。
  1. メインラインから最新バージョンを取得します（subversionの「trunk」、gitの「master」、...）
  2. ファイルを修正する
  3. 「更新」コマンドを使用して、メインラインからの最新バージョンで変更をマージします
  4. メインラインにコミット
• 分散システムでは：
  1. メインラインから最新バージョンを入手する
  2. ファイルを修正する
  3. ローカルでコミットする
  4. メインラインからの最新バージョンで変更をマージし、結果をローカルにコミットします
  5. メインラインにプッシュします。

分散バージョンでは、以前のヘッドリビジョンを完全にマージしないリビジョンをプッシュすることはできません（特別なオーバーライドなしで、時には有用です）。したがって、マージステップを実行せずに通過することはありません（したがって、誰かが2つのバージョンを作成することはありません）あなたが懸念しているように統合する必要があります）。

ここで、4つのステップは用語を除いて同じですが、分散システムは追加のステップ「3.ローカルでコミット」を追加することに注意してください。この手順の大きな利点は、更新/プルが競合を作成し、それらを解決する方法や間違いを解決する方法がわからない場合、戻って、行ったことを確認し、マージをやり直すことができることです。Subversionはそれらのいずれも記憶しませんので、もしあなたが更新を解決するのを間違えたら、あなたは台無しにされます。

変化の蓄積に関しては、人々は集中システムでもそうする傾向があります。特に、機能を頻繁に切り替える必要がある場合（バグを修正するためにいくつかの長い作業を中断したり、顧客が緊急に必要とする何らかの調整を行うなど）、人々は多くの場合、変更が完了していないために変更をローカルに保持する必要があります。そのため、システムが少なくともそれを理解することをサポートしている方が良いです。

いずれの場合も、これらの問題は、ツールではなく、チーム内の適切なガイドラインとコミュニケーションで対処する必要があります。柔軟性の高いツールでは、ガイドラインがより重要になりますが、柔軟性の高いツールを使用すると、さまざまなコーナーケースにより適切に対処できます。