タグ付けされた質問 「branching」

この記事「成功したGit分岐モデル」は、経験豊富なDVCSユーザーの間で非常によく知られていると思います。 私はhg主に使用しますが、この議論はどのDVCSでも問題ないと主張します。 現在のワークフローは、各開発者がマスターリポジトリのクローンを作成することです。独自のローカルリポジトリにコードを記述し、テストを実行し、すべてがうまくいけばマスターにプッシュします。 そこで、JenkinsのようなCIサーバーをセットアップし、将来のプロビジョニングシステム（シェフ、パペット、アンシブルなど）でワークフローを改善したいと考えています。 実部 さて、上記のモデルはうまく機能しますが、ブランチはCIを壊す可能性があります。機能ブランチは、developmentCIとマージをスムーズにするために、オリジンと同期する必要があります（記事によると、ブランチになります）。 アリスとボブが2つの機能に取り組んでいると言います。しかし、アリスは翌日に行われます。ボブの機能には1週間かかります。Bobが完了するまでに、彼の変更は古くなっています（おそらく、Aliceは一部のクラスをリファクタリング/名前変更しています）。 1つの解決策は、毎朝、開発者がプルmaster/originして、変更があるかどうかを確認する必要があることです。Aliceがコミットした場合、Bobは自分のワークスペースにプルしてマージし、機能ブランチが最新になるようにします。 これは良い方法ですか？ これらのブランチは（ローカルクローンではなく）マスターリポジトリに存在する必要がありますか？つまり、すべての開発者がGitHub / Bitbucketのマスターリポジトリにコミット権限を与えて、新しいブランチを作成できるようにする必要がありますか？または、これはローカルで行われますか？ 最後に、記事が提示するモデルは、ブランチがと同期していない場合、CIを破壊する必要がありorigin/masterます。ナイトリービルドを実行したいので、開発者は仕事を離れる前にプルしてマージし、各機能ブランチでもCIを実行する必要がありますか？

18 git  continuous-integration  mercurial  dvcs  branching 

私は最終的にはオープンソースになるプライベートプロジェクトに参加しています。私たちには、アプリを構築するための技術に十分な才能がある少数のチームメンバーがいますが、クリーンで美しい、最も重要な長期保守可能なコードを書くことができる専任の開発者はいません。 コードベースのリファクタリングを開始しましたが、定期的に連絡を取り合っていない別の国にいるチームの誰かがこのまったく別のものを更新する可能性があるため、少し扱いに​​くいです。 解決策の1つは、迅速に通信するか、より良いPMプラクティスを採用することですが、まだそれほど大きくはありません。コードをクリーンアップして、彼が更新したものにうまくマージしたいだけです。ブランチを使用することは適切な計画でしょうか？ベストエフォートマージですか？他に何か？

18 open-source  version-control  git  refactoring  branching 

私たちのチームは、FogBugz＆Kiln / MercurialからJira＆Stash / Gitに切り替えました。ブランチにはGit Flowモデルを使用し、機能ブランチからサブタスクブランチを追加しています（Jira機能のJiraサブタスクに関連）。プルリクエストを作成して親ブランチにマージするときにStashを使用してレビュアーを割り当てます（通常は開発しますが、サブタスクは機能ブランチに戻ります）。 私たちが見つけている問題は、複数の開発者が同じ機能、たとえばフロントエンドとバックエンドで相互に依存しているコードで作業している場合、機能ケースの最適な計画と内訳でもです。別のブランチでは、1人の開発者が他の開発者をブロックします。 開発中に、お互いのブランチ間をプルしようとしました。また、各開発者が複数のブランチからプルして、開発時に統合をテストできるローカル統合ブランチを作成しようとしました。最後に、これはこれまでのところ私たちにとっておそらく最もうまく機能しているようですが、もう少しオーバーヘッドがありますが、機能ブランチからすぐに統合ブランチを作成しようとしました。サブタスクブランチ（機能ブランチ外）がプルリクエストとコードレビューの準備ができたら、これらの変更セットをこの機能統合ブランチに手動でマージします。その後、関心のあるすべての開発者は、その統合ブランチから他の依存サブタスクブランチにプルできます。これにより、コードレビューに合格するために依存しているブランチを誰も待つことができなくなります。 これは必ずしもGitの問題ではないことを知っています。これは、独自の作業プロセスと文化が混在する、複数のブランチで相互依存するコードを操作することに関係しています。開発（厳密な統合ブランチ）のための厳格なコードレビューポリシーがない場合、開発者1は、開発者2が引き出せるように開発にマージできます。もう1つの複雑な点は、QAに機能を渡す前に、コードレビュープロセスの一部としていくつかの予備テストを行う必要があることです。バックエンド開発者2が終了し、プルリクエストがコードレビューに1週間座っている場合、フロントエンド開発者2はコードレビューアができないため、技術的にプルリクエスト/コードレビューを作成できませんバックエンド開発者2 'のためのテスト 結論として、これらのインスタンスでは、どのルートに行くかに応じて、パラレルではなくはるかにシリアルなアプローチで自分自身を見つけており、これを回避するために使用するプロセスを見つけたいと考えています。 最後に言及することは、コードのレビューとファイナライズが完了していないブランチ間でコードを共有することで実現していますが、本質的には他のベータコードを使用しています。ある程度まではそれを避けることはできないと思いますし、ある程度それを受け入れるつもりです。

17 git  workflows  branching  jira  gitflow 

2つのバージョンを持つゲームプロジェクトがあります。 ゲームのシンプルなバージョン、コア。 ゲームの高度なバージョン。 私は自分の公開リポジトリに最初のバージョンがあり、私だけがそれに取り組んでいます。2番目のバージョンについては、私の2人の友人と私がそれに取り組みます。重要な部分は、2つのバージョンをリポジトリに残すことです。 私はこれにブランチを使用するかもしれないと考えましたが、この質問とその答えを考慮すると、バージョン管理の観点からそうするのは良い習慣ではありません。私が知る限り、自分のリポジトリをフォークすることはできません。 ここで私のオプションは何ですか？リポジトリに両方のバージョンを保持するにはどうすればよいですか？

17 git  github  branching  forking 

私はGitリポジトリを成功したGit分岐モデルに基づいており、この状況になったらどうなるのかと考えていました。 2つの機能ブランチAとBで開発しており、BにはAからのコードが必要であるとします。Xノードは機能AにブランチBに影響するエラーを導入しますが、機能AとBがマージされたノードYでは検出されず、テストは、再び分岐して次の反復に取り組む前に実施されました。 その結果、機能Bで作業している人々がノードZでバグを見つけました。この段階で、バグ修正が必要であると判断されました。この修正は両方の機能に適用する必要があります。これは、機能の一部であるため、機能Aで作業している人々もバグを修正する必要があるためです。 バグ修正ブランチを最新の機能Aノード（ノードYから分岐するノード）から作成し、機能Aとマージする必要がありますか？その後、両方の機能が再び開発にマージされ、分岐する前にテストされますか？ この問題は、問題を解決するために両方のブランチをマージする必要があることです。フィーチャーBはフィーチャーAのコードに触れないため、修正を実装し、フィーチャーBブランチをマージせずにフィーチャーAの修正コードを保持することにより、ノードYの履歴を変更する方法はありますか？ 軽度の関連：Gitバグの分岐規則

16 git  bug  branching 

私たちのチームでは、個々の作業単位（ストーリー）に加えて、より長時間実行される作業テーマ（叙事詩）があります。複数のストーリーが壮大です。 従来、各ストーリーに機能ブランチがあり、それらがQAに合格したときにそれらを直接マスターにマージしました。ただし、Epicが「機能完了」と見なされるまで、Epicで完了したストーリーのリリースを控えたいと思います。これらの機能は、Epic全体が閉じられたときにのみ本番環境にリリースされます。さらに、ナイトリービルドサーバーがあります-すべての閉じられたストーリー（不完全なEpicsの一部を含む）がこのナイトリーサーバーに自動的にデプロイされるようにします。 これを達成するためのレポの管理方法に関する提案はありますか？「エピックブランチ」を導入することを検討しました。ここでは、クローズドストーリーをマスターに直接ではなく、関連するエピックブランチにマージしますが、私の懸念は次のとおりです。 壮大なブランチを長時間開いたままにしておくと、マージの競合が心配です ナイトリービルドでは、すべてのエピックブランチを「ナイトリービルド」ブランチにマージする必要があります。繰り返しますが、マージの競合が発生する可能性があり、これは自動的に行われます

15 version-control  git  maintenance  branching 

私たちの仕事には、多くの基本機能を共有するいくつかの異なる.netアプリケーションがあります。クリーンなn層アーキテクチャを使用してこれらのアプリケーションを構築しましたが、同じ機能を何度か再実装したことに気付いたその瞬間にヒットしました。これは明らかにDRYに違反するため、修正する必要があります。すでに一般的なグルーコード（IoCの配線、ログ、設定）にNugetを使用していますが、すべてのアプリケーション間でデータ層とビジネス層を共有したいと考えています。このアイデアは、UIが実際に必要なビジネスレイヤーの部分のみを処理するというものです。 これは最初は簡単な問題のように見えますが、進行中の開発には落とし穴があり、どのように進めればよいかわかりません。すべてを支配するために1つのビジネスレイヤーを作成するとします。簡潔にするために、「Foundation」と呼びます。Foundationを使用するためにアプリケーションを移植しましたが、すべてが素晴らしいものです。Foundationはnugetを介してライトUIレイヤーに配布されており、見栄えが良いです。しかし、その後、アプリケーションに機能を追加し始め、トラブルに直面します。 プロジェクトAに取り組んでおり、Foundationの変更を必要とする新しい機能を追加するとします。Foundation（Foundation-A）に変更を加え、不安定なパッケージとしてNugetフィードにプッシュします。プロジェクトAは最新のnugetパッケージを取得し、すべてが良好です。一方、別の開発者がプロ​​ジェクトBに取り組んでいます。彼はソース管理から最新のFoundationを取得しますが、安定したブランチから取得するため、プロジェクトAの変更はありません。彼は変更を加え、Foundation-Bを作成しました。そして、すべてが良いです。しかし、その後、実際にコードを共有できるFoundation-AとFoundation-Bの実装機能を発見したため、それらを組み合わせます。一方、Foundation-Cは独自の変更を加えてそこに浮上しています。最終的に、Foundation-Bの運用準備が整いました。しかし、その後、プロダクションA、B、 これはうまくいくように思えますが、異なるデータベーススキーマで作業し、FoundationリポジトリのさまざまなブランチとプロジェクトA、B、Cリポジトリ間ですべてを同期させることを心配しています。おそらく多くの手作業が必要になるようで、エラーの可能性が広がります。これを可能な限り自動化したいと思います。 使用しているスタックは次のとおりです。C＃、継続的インテグレーションを備えたTFS、Nuget。当社のアプリケーションはすべて、さまざまな種類のASP.NETアプリケーションです。物事を簡単にする場合は、さまざまなSCMを検討します。 さまざまなソースコードブランチでNugetを正常に保つ方法を探しています。間違ったNugetパッケージを参照するため、誤って開発コードを本番環境にプッシュしたくありません。

14 c#  team-foundation-server  branching 

バージョン管理管理システムで多くのコンポーネントを持つ大きなプロジェクトを管理する方法を知りたいです。 私の現在のプロジェクトには、4つの主要な部分があります。 ウェブ サーバ 管理コンソール プラットホーム。 Webとサーバーの部分は、私が書いた2つのライブラリーを使用します。合計で5つのgitリポジトリと1つのmercurialリポジトリがあります。プロジェクトビルドスクリプトはプラットフォームリポジトリにあります。構築プロセス全体を自動化します。 問題は、複数のコンポーネントに影響する新しい機能を追加するときに、影響を受ける各レポジトリに対してブランチを作成する必要があることです。機能を実装します。それを元に戻します。私の直感は「何かが間違っている」です。 単一のリポジトリを作成し、そこにすべてのコンポーネントを配置する必要がありますか？その場合、分岐が簡単になると思います。または、私が今やっていることをやるだけです。その場合、各リポジトリにブランチを作成するこの問題をどのように解決しますか？

13 version-control  branching  configuration-management  merging 

注： 私の質問は、特定の問題（Liferayを含む）に焦点を当てていますが、gitで同じプロジェクトのさまざまなバージョンを維持する必要がある人にとって役立つことを願っています。 私はLiferay Portalの多くのプラグインを書いている会社で働いています。これらのプラグイン（ポートレット、テーマなど）は通常再利用可能であり、もちろん、ポータルの新しいバージョンに合わせて更新する必要があります。 しかし、移行する必要があり、私たちは、言うのLiferayの新バージョンへのポートレットせることが通常であるとその前のバージョンを維持します。また、一部のクライアントに対して非常に具体的なカスタマイズを作成する必要が頻繁にありますが、これは「メインバージョン」に追加しても意味がありません。 これらの要件により作業が複雑になりますが、幸いなことに、いくつかの単純化を想定できます。たとえば、プラグインは一度に1人のプログラマのみが頻繁に更新します。プラグインに複数の機能を同時に追加することは非常にまれです。 現在、Gitoriousに移行しています。このようなシナリオの分岐モデルを考えています。 私のモデル 私が提案したのは： 各プラグインには、プロジェクト内のGitoriousに独自のリポジトリがあります。たとえば、子猫を表示するためのポートレットにはkittens-portlet、liferay-portletsプロジェクト内にリポジトリがあります。 新しいプラグインを作成するときは、Liferayバージョンに応じて名前が付けられたブランチ（たとえば、lf5.2）に作成します。 プラグインで更新が行われるたびに、更新は本番環境で承認およびデプロイされ、プラグインにバージョン（たとえばlf5.2v1、lf5.2v2など）のタグが付けられます* プラグインをLiferayの新しいバージョンに移植するたびに、最新バージョンをブランチします（たとえば、ブランチを作成しlf6.0ます）。 本番環境に入ると、新しいブランチのヘッドはなどのタグを受け取りlf6.0v1ます。 クライアント固有の方法でプラグインをカスタマイズする必要があるたびに、クライアントの名前でブランチを作成します（たとえば、lf5.2clientcorpクライアント「ClientCorp Inc.」のブランチを作成します） これは通常とは異なるモデルですmaster。マージされないブランチはまったくなく、多くあります。これは、そのようなモデルを持つリポジトリが次のように見えると思う方法です： 友人がこのシステムをかなり複雑でエラーが発生しやすいと感じました。彼は、優れた人気のあるVincent Driessenモデルを提案しました。もちろん素晴らしい（そしてテスト済み！）が、私たちの状況には複雑すぎるようだ。 私の友人のモデル 次に、彼は別のモデルを提案しました。Liferayバージョンの各プラグインのリポジトリを作成し（したがって、を作成しkittens-lf5.2-portlet、次にを作成しますkittens-lf6.0-portlet）、それぞれにmasterブランチとdevelopブランチがあります。これmasterにより、いつでも展開の準備が整います。（それとも、他の方法で回避することが、可能性masterとstableによって示唆されているように、スティーブLosh）。 これは非常に簡単ですが、私はこのシステムが好きではありませんでした： その結果、プロジェクトに膨大な数のリポジトリが作成され、Gitoriousの閲覧が困難になる可能性があります。 プロジェクトのディレクトリの名前が関連しています。誰かがリポジトリをkittens-lf6.0-portletディレクトリにクローンし、antを使用してWARを生成する場合（通常どおり）、WAR名kittens-lf6.0-portletも同様になります。このポートレットの古いバージョン（kittens-portletたとえば、名前が付けられている）は、アップグレードされたポータルでは異なる（おそらく欠落している）ポートレットと見なされます。少し注意すれば回避できますが、回避したいです。 同じプラグインの異なるバージョンは別々に維持されます。私は私の心を壊します:( kittens-lf6.0-portlet リポジトリのい名前だと思います。 私は、2つの最後のポイント-これも2つのより主観的なポイント-が私の不本意の主な理由だと思います。それにもかかわらず、すべての4つの異議が立っています。 OTOH、私自身の提案は私には奇妙に思われ、それに隠されたバグがあるのだろうかと思います。OT3rdH gitは非常に強力で柔軟性があるため、その可能性を探ることに恥ずかしさは感じないと思います。 だから、私は尋ねます： 最高のモデルは何でしょうか？わたしの提案？友達のモデル？今では伝統的なビンセント・ドリーセンのシステムですか？ 他にどのような分岐モデルを提案しますか？ 私のモデルが悪いと思うなら、なぜそう思うのですか？私は欠点と盲点が何であるかを学びたいです。 *実際には、次のようなバージョンでコミットにタグ付けすることを好みますv1が、どうやらgitのタグはブランチ内でスコープされていません-つまり、1 つのv1タグlf5.2ともう1つのタグを持つことはできませんでしたlf6.0ので、ブランチ。それは正しいですか？

13 version-control  git  branching 

現在、次のような状況にあり、サブ機能ブランチに対して機能ブランチがブランチされています（同じ機能のバックエンドとフロントエンドの作業など）。 o | o development |\ | o feature-a | | | o | |\ | | o feature-a-sub | | | | | | | \ | o merged feature-a into feature-a-sub | / o feature-a-sub merged into development | | | o feature-a with future work on it …

12 git  branching 

この質問のフォローアップとして： 自分でチームで作業している場合、ブランチをマージするときに、すべてのコミットを1つの差分にまとめてからその差分をマージすることで、有用なコミットメッセージを維持できます。そうすれば、ブランチでどのような変更が導入されたかを簡単に確認できます。また、マスターブランチを参照するときに、そのブランチで達成された機能/変更/その他を説明する1つの要約があります。 私の質問は、チームで作業するときにこれをどのように達成できますか？その状況では、ブランチはリモートリポジトリにプッシュされます。つまり、ブランチ内のすべてのコミットを1つのコミットにまとめることはできません。ブランチがパブリックである場合、マスターブランチで有用なマージコミットを1つ持つことができますか？（「有用」とは、マスター行のコミットが（1）ブランチで行われた内容の有用な要約と（2）同じものの差分を示すことを意味します。）

12 git  branching 

私はかなり大規模なアジャイルチームのソフトウェア開発者です（8人の開発者が1つのコードリポジトリに積極的に変更を加えています）。2週間ごとに、ソフトウェアの新しいバージョンを運用環境にプッシュします。現在のワークフローは次のとおりです。 新しいタスクを開始するとき、開発者はメインの開発ブランチ（gitを使用）から「機能ブランチ」を作成し、この新しいブランチで作業します 開発者がタスクの作業を完了すると、機能ブランチを開発ブランチにマージして戻します 開発者は、開発ブランチをQAブランチにマージします。 QAブランチからビルドがトリガーされます。このビルドの出力はQA環境に展開され、テスターがテストを開始できるようにします。 テスターがQAブランチにマージされたこれらの新機能の問題を見つけることは非常に一般的です。これは、常に、QA環境にいくつかの新しい機能が含まれていることを意味します-テスト済みでバグのないもの、壊れたものなど。QAビルドが実稼働対応状態になることはまれなので、これによりリリースが困難になります。 これを軽減するために、開発者がリリースの数日前に開発ブランチをQAブランチにマージしないことを意味する「QAフリーズ」を開始しようとしました。QA環境のバグ修正はQAブランチで直接行われ、開発ブランチにマージされます。理論的には、これによりQAの新しい壊れた機能が排除され、QAで既に発生している問題を修正できます。 この「QAフリーズ」の概念は部分的には成功していますが、調整が難しく、QAへのマージが許可されているかどうかについて人々はしばしば混乱します。また、「QAフリーズ」の期限を設定することは困難でした。誰もがフリーズとリリースの間に息を吹き込む部屋のアイデアを好みますが、実際には、デッドラインを尊重するよりも次のリリースで機能を持ちます。 1週間おきにリリースのクリーンビルドを確保するより良い方法はありますか？

12 agile  version-control  development-process  branching  release-management 

あなたが見つけたよりも良い状態にコード/キャンプサイトを残すことについてのこの記事が本当に好きです -コードの清潔さを維持するための現実の現実的なアプローチのようです。 また、機能を単独で開発する方法として機能ブランチが本当に好きなので、気に入らない場合は簡単にマージできないなどです。 ただし、機能ブランチで作業しているときにifいコードを見つけた場合、修正する必要がありますか？ それを修正するには多くの欠点があるように感じます： ブランチをマージして戻すと、diffが乱雑になり、変数名の変更や関数の抽出が乱雑になります 機能が放棄された場合、クリーンアップコミットをチェリーピック（近くのコードが変更されて乱雑なマージが行われた方法に応じて機能する場合と機能しない場合があります）、再実行、または単に放棄する必要があります。 反対に、ファイルにいるときに実行しないと、ブランチをマージする数日後に実行するのを忘れることになります。 私はこれが意見に基づいていると警告されました（タイトルに含まれている事実から外れていると思いますshould）が、答えがあると感じています（確かに人々は両方のアプローチを使用しているので答えが必要です）。また、についての質問development methodologiesは話題になっており、ある程度の意見が必要だと思います。

11 refactoring  code-quality  branching 

私たちはプロジェクトを行っていますが、プロジェクト間で多くのコードを再利用し、共通のコードを含むライブラリをたくさん持っています。新しいプロジェクトを実装するにつれて、一般的なコードを抽出してライブラリに追加する方法が増えています。ライブラリは互いに依存し、プロジェクトはライブラリに依存します。各プロジェクト、およびそのプロジェクトで使用されるすべてのライブラリは、参照しているすべてのライブラリの同じバージョンを使用する必要があります。ソフトウェアをリリースする場合、バグを修正する必要があり、長年、場合によっては数十年にわたって新しい機能を追加する必要があるかもしれません。約12のライブラリがあり、変更は多くの場合2つ以上にまたがり、複数のチームが複数のプロジェクトを並行して作業し、これらすべてのライブラリに同時に変更を加えます。 最近、gitに切り替えて、各ライブラリおよび各プロジェクトのリポジトリを設定しました。stashを共通のリポジトリとして使用し、機能ブランチで新しい作業を行い、プルリクエストを作成し、レビュー後にのみそれらをマージします。 プロジェクトで対処しなければならない問題の多くは、いくつかのライブラリとプロジェクト固有のコードを変更する必要があります。多くの場合、ライブラリインターフェイスの変更が含まれますが、その一部には互換性がありません。（これが怪しいと思うなら、私たちはハードウェアとインターフェイスし、特定のハードウェアを汎用インターフェイスの後ろに隠します。他のベンダーのハードウェアを統合するたびに、現在のインターフェイスが予期しなかったケースに遭遇するため、それらを改良する必要があります。）たとえば、プロジェクトを想像しP1たライブラリを使用してL1、L2とL3。L1また、使用していますL2とL3、とL2用途L3にも。依存関係グラフは次のようになります。 <-------L1<--+ P1 <----+ ^ | <-+ | | | | +--L2 | | ^ | | | | +-----L3---+ ここで、このプロジェクトの機能に変更が必要でP1ありL3、のインターフェースを変更することを想像してくださいL3。これらのライブラリを参照するプロジェクトP2をP3ミックスに追加します。それらをすべて新しいインターフェイスに切り替え、すべてのテストを実行し、新しいソフトウェアを展開する余裕はありません。それでは、代替手段は何ですか？ 新しいインターフェースを実装する L3 プルリクエストをL3してレビューを待ちます 変更をマージする の新しいリリースを作成する L3 の新しいリリースをP1参照することで機能の作業を開始し、機能のブランチにL3機能を実装しますP1 プルリクエストを行い、これをレビューして、マージします （私はちょうど私がスイッチに忘れたことに気づいたL1とL2新しいリリースに。そしてそれはと並行して行われる必要があるので、私も、どこでこれを固執するかわかりませんP1...） これは、この機能を実装するための退屈でエラーが発生しやすい非常に長いプロセスであり、独立したレビューが必要であり（レビューがはるかに困難になります）、スケーリングがまったく行われず、私たちがビジネスを停止する可能性がありますプロセスが行き詰まってしまい、何もできなくなります。 しかし、あまり多くのオーバーヘッドなしで新しいプロジェクトに新しい機能を実装できるプロセスを作成するために、どのように分岐とタグ付けを使用するのでしょうか？

11 git  branching  dependencies  scm  tagging 

新しいプロジェクトの新しい開発チームから始め、ソースリポジトリ（Microsoft Team Foundation Server 2010など）の分岐戦略を定義する必要があります。私たちは...するべきかどうかという難しい議論にぶつかりました... A。実稼働ビルドを行うリリースブランチが1つあり、実際に何かがリリースされたときにラベルを付ける または B。本番環境への新しいリリースごとに新しいリリースブランチを作成します（例：バージョン1、2、3など...） オプションAは非常に簡単に思えますが、これが長期的に問題を引き起こすかどうかはわかりません。オプションBは、時間の経過とともに積み重なる1回限りの長寿命ブランチを作成するだけのようです。 私たちが決めるのを助けることができる経験はありますか？具体的には、いずれか1つの選択肢のどこに問題があるのか​​を聞きたいと思っています。TFSおよび/またはリリース管理の意味に関連する特定の経験を提供してください。

11 version-control  team-foundation-server  release-management  branching