2

現在、ソース管理を管理するためにTFS 2010を使用しています（MSショップなので、デフォルトの選択でした）。

スタンドアロンプ​​ロジェクトでは問題ありません。ただし、クライアントごとにオーダーメイドしたコア製品があります。多くのクライアントは非常に重要なカスタマイズを必要としますが、他のクライアントはほんの少しの微調整を必要とします。

私たちはそれが悪夢であることに気づいています。基本的に、コア製品を含むチームプロジェクトがあります。クライアントが変更を必要としない場合は、コア製品をデプロイするだけです。彼らが変更を求めた場合、私たちはコア製品チームプロジェクトを分岐させ、それに取り組み始めます。

したがって、変更が必要な単一のファイルでは、製品全体を分岐する必要があります。私たちはこれを間違っていますか？私は、各クライアントが必要とする主な製品との違いを含むブランチを作成することを想像しました。次に、基本的にクライアントはコアと必要な変更を取得します。次に、コアに追加または変更すると、自動的に取得されます。

私たちは常にコアを開発しているので、すべての分岐プロジェクトに変更をマージすることに人生を費やしているように見えました。現在5つのクライアントがありますが、来年には15〜20のパイプラインがあります。しかし、私たちが5で行っている作業を考えると、これは完全に管理できないように思われます。プログラマーとしての私たちの生活は、マージ後にマージするだけのようです。これは、製品がまったく新しいため、コアのチャーンが多いためです。しかし、私たちは常にコアを開発し続けたいと思います。問題は、私たちの誰もがこのようなプロジェクトに取り組んだことがないということです。そのため、これが私たちがそれをどのように扱うべきかがわかりません。

このコア/ブランチ/エンドレスマージ全体が私たちを悲しませてくれるので、誰かが何か考えを持っていますか？誰かが私の同僚の一人に、gitは私たちが何かを見るのに役立つだろうと提案しました。

ありがとう

4

3 に答える 3

5

基本製品と分岐製品に同じファイルの異なるバージョンがある場合、使用しているソース管理製品に関係なく、マージが発生します。一部（Gitなど）では分岐とマージがかなり簡単になり、一部（TFSなど）ではかなり重い操作になりますが、マージはまだ実行する必要があります。

処理を非常に簡単にする戦略の1つは、コードをより管理しやすい部分に分割し（SOLIDが頭に浮かぶ）、顧客固有のクラスへの適応を分割することです。顧客の適応のために個別のファイルがあり、構成の変更だけを使用してクラスを注入できる場合、顧客固有の変更のために分岐する理由はまったくありません。顧客固有のクラスへの最悪の変更は、開発中の顧客を壊すことです。これにより、バージョン管理のためのブランチ（つまり、開発/テスト/リリースブランチ）が継続されますが、バージョン管理および顧客固有のブランチは取得されません。

于 2012-08-26T13:16:38.073 に答える
3

コードの構造によっては、TFSの部分的なブランチを利用できる場合があります。メインブランチの名前が「Main」で、「a」、「b」、「c」、「d」の4つのサブフォルダーがあるとします。「d」のみを変更することがわかっている場合は、「d」を新しいブランチにブランチするだけです。これは「Feature1」と呼ばれる場合があります。

したがって、TFSでは次のフォルダー構造になります。

Main/
    a/
    b/
    c/
    d/

Feature1/
    d/

ここで、この部分的なブランチを適切に使用するための秘訣は、Feature1で作業しているときに正しいワークスペースマッピングを設定することです。必要なのは、a / b/とc/をMainから取得し、d/をFeature1から取得することです。次のマッピングを使用できます。

(active) C:/dev/Feature1 -> $/TeamProject/Main
(cloaked) $/TeamProject/Main/d
(active) C:/dev/Feature1/d -> $/TeamProject/Feature1/d

したがって、ワークスペースでは、a、b、およびcは、メインブランチで変更されると更新され、dは機能ブランチでの変更のみになります。マージする場合、dの変更のみをマージして解決する必要があります。

これで問題は解決しますが、かなり複雑であることを理解する必要があります。Feature1での作業中に、誤ってa、b、またはcの変更をチェックインすることを妨げるものは何もありません。これらの変更は、メインブランチに直接反映されます。また、Mainの変更から自分を隔離しないことにより、他の開発者はa、b、またはcに変更を加えて、Mainでビルドの中断を引き起こさないが、dでビルドの中断を引き起こす可能性があります（dがa、b、またはcに依存していると仮定）。

部分的なブランチを作成する方法についての良いリンクがあります。

もう1つの注意点として、任意のレベルでファイルとフォルダーの部分的なブランチを作成できます。トップレベルのフォルダだけに限定されません。

于 2012-08-27T10:32:40.647 に答える
2

gitは、TFSに2つの利点をもたらします。

まず、gitブランチでは、作成が簡単で迅速であり、TFSが要求するような計画や継続的な概念の負荷を要求しません。次に、そして最も重要なこととして、gitを使用すると、マージではなくリベースを使用して、ブランチ間で変更を移動できます。これは、調整をクリーンで簡単に保ち、ブランチ開発とトランクを明確に区別するのに役立ちます。

また、TFSにリポジトリを保持しながら、gitを操作できる優れたツールgit-tfsがあります。これは、gitに移行している間、または会社が今後TFSに「マスター」リポジトリを保持することを要求している場合に役立ちます。

注意点：gitは状況に応じて機能すると思いますが、gitのドキュメントの多くでカバーされているユースケースではありません。多くのgitの記述は分岐とマージに焦点を合わせていますが、あなたのような場合の利点は分岐とリベースであると思います。gitを実際に「取得」して、殴られた道から外れたときに正しいことを知るまでには、使用期間がかかる傾向があります（そして、ユースケースの実行方法を詳細に説明することは、StackOverflowの範囲を超えています）。あなたのチームがそれを降ろす少し前に。

于 2012-08-26T13:19:28.420 に答える