GitとTeam Foundation Server
開発チームにGitを紹介しましたが、私以外は誰もがGitを嫌っています。彼らはそれをTeam Foundation Serverに置き換えたいと考えています。 TFSについてはあまり詳しくありませんが、これは大きな後退だと思います。経験のある人がTFSの分岐サポートとGit分岐を比較できますか？また、一般的に、TFSの長所と短所は何ですか？ Gitを数年間使用した後、私はそれを嫌いますか？
私は思う、声明
私を除いて誰もがそれを嫌う
これ以上の議論は無駄になります。Gitを使い続けると、何か問題が発生した場合にyouのせいになります。
これとは別に、私にとって、Gitには集中型VCSよりも2つの利点があります。これは私が最も感謝しています（一部は Rob Sobers によって説明されています）。
- レポ全体の自動バックアップ：誰かが中央レポからプルするたびに、彼/彼女は変更の完全な履歴を取得します。 1つのリポジトリが失われた場合：心配しないで、すべてのワークステーションに存在するリポジトリの1つを取ります。
- オフラインレポアクセス：自宅（または飛行機や電車）で作業しているとき、プロジェクトのすべての履歴を見ることができます。チェックイン。VPN接続を起動せずに動作し、私のように動作しますwere work：checkin、checkout、branch、anything。
しかし、私が言ったように、私はあなたが負けた戦いと戦っていると思います：誰もがGitを憎むとき、Gitを使用しないでください。 なぜ彼らがGitを嫌うのか説得しようとするのではなく、もっと知るのに役立ちます。
彼らが単にそれを望んでいないなら、それは彼らにとって新しいものであり、新しいことを学ぼうとしないからです。あなたはそのスタッフで成功した開発をすることを確信していますか？
本当にすべての人がGitを嫌っていますか、それともオピニオンリーダーの影響を受けていますか？リーダーを見つけて、何が問題なのか尋ねてください。彼らを説得し、あなたはチームの残りを説得します。
リーダーを説得できない場合：Gitの使用を忘れて、TFSを使用してください。あなたの人生を楽にします。
2つのシステムの主な違いは、TFSが集中バージョン管理システムであり、Gitが分散バージョン管理システムであることです。
TFSでは、リポジトリは中央サーバーに保存され、開発者は特定の時点でのコードのsnapshotである作業コピーをチェックアウトします。 Gitを使用して、開発者はリポジトリ全体をすべての履歴を含むマシンに複製します。
開発者のマシンに完全なリポジトリを配置する利点の1つは、サーバーが停止した場合の冗長性です。もう1つの良い点は、サーバーと通信することなく、リビジョン間で作業コピーを前後に移動できることです。これは、サーバーがダウンしているか、単に到達できない場合に役立ちます。
私にとっての本当の恩恵は、サーバーと通信したり、チームに潜在的に不安定な変更を加えたりすることなく、ローカルリポジトリへの変更セットをcommitできることです（すなわち、ビルドを壊します）。
たとえば、大きな機能に取り組んでいる場合、完全にコードを作成してテストするには1週間かかる場合があります。不安定なコードを週中にチェックインしてビルドを中断したくありませんが、週の終わりに近づいていて、誤って作業コピー全体を誤って使用してしまった場合はどうなりますか？ずっとコミットしていなかったら、仕事を失うリスクがあります。これは効果的なバージョン管理ではなく、TFSはこの影響を受けやすくなっています。
DVCSを使用すると、変更をコミットするため、ビルドを壊す心配をせずに常にコミットできますローカル。 TFSおよびその他の集中システムでは、ローカルチェックインの概念はありません。
DVCSでの分岐とマージの改善については詳しく説明していませんが、SOまたはGoogleで多くの説明を見つけることができます。経験から、TFSでの分岐とマージは良くないことがわかります。
組織でのTFSの議論が、GitよりもWindowsの方がうまく機能するという議論であれば、Windowsでうまく機能するMercurialをお勧めします-Windows Explorer（TortoiseHg）およびVisual Studio（VisualHg）との統合があります。
人々は銃を下ろし、棚から離れ、そして思考を1分間する必要があります。 DVCSには、チームの生産性に大きな違いをもたらす客観的、具体的、そして否定できない利点があります。
それはすべて分岐とマージに帰着します。
DVCSの前の指針は、「神に祈り、分岐し、合流する必要がないようにします。そして、そうするなら、少なくとも神に非常に簡単なことを請う」ことでした。
現在、DVCSを使用すると、分岐（およびマージ）が大幅に改善され、基本原則は次のようになります。「ほんの一瞬でそれを実行します。問題。」
そして、それはどのチームにとっても大きな生産性の向上になります。
問題は、人々が私が今言ったことを理解し、それが真実であると確信するために、彼らは最初に少し学習曲線に投資しなければならないことです。彼らはGitやその他のDVCS自体を学ぶ必要はありません...彼らはGitがどのように分岐とマージを行うかを学ぶ必要があります。いくつかの記事とブログの投稿を読んで読み直し、ゆっくりと読んで、それが見えるまで作業してください。 2〜3日間の大部分の時間がかかる場合があります。
しかし、一度それを見れば、非DVCSを選択することさえ考えないでしょう。なぜなら、DVCSには明確で客観的で具体的な利点があり、最大の勝利は分岐とマージの分野にあるからです。
Original：@ Rob、TFSには「 Shelving 」と呼ばれるものがあり、それなしで進行中の作業をコミットすることに対する懸念に対処します公式ビルドに影響します。中央バージョン管理が障害とみなされていることは理解していますが、TFSに関しては、シェルフへのコードのチェックは強度b/cと見なすことができ、まれに中央サーバーが進行中の作業のコピーを保持しますローカルマシンがクラッシュしたり、紛失/盗難にあったり、ギアをすばやく切り替える必要があります。私のポイントは、TFSがこの分野で適切に称賛されるべきだということです。また、TFS2010での分岐とマージは以前のバージョンから改善されており、「... TFSでの分岐とマージが良くないという経験から」と言うとき、どのバージョンを参照しているかは明確ではありません。免責事項：私はTFS2010の適度なユーザーです。
2011年12月5日編集：OPにとって、TFSについて気になる1つのことは、すべてのローカルファイルを「読み取り-作業していないときのみ。変更を加える場合、フローはファイルを「チェックアウト」する必要があります。これにより、ファイルの読み取り専用属性がクリアされるだけなので、TFSはファイルを監視し続けます。それは不便なワークフローです。私がそれを動作させることを好む方法は、変更を行ったかどうかを自動的に検出するだけであり、ファイル属性をまったく気にせず、まったく気にしません。そうすれば、Visual Studio、メモ帳、または任意のツールでファイルを変更できます。この点に関して、バージョン管理システムは可能な限り透過的でなければなりません。 Windowsエクスプローラー拡張機能（ TFS PowerTools ）を使用すると、Windowsエクスプローラーでファイルを操作できますが、ワークフローはあまり簡素化されません。
言われたことすべてに加えて（
https://stackoverflow.com/a/4416666/172109
）、これは正しい、TFSは単なるVCSではありません。 TFSが提供する1つの主要な機能は、ネイティブに統合されたバグ追跡機能です。変更セットは問題にリンクされており、追跡できます。チェックインのさまざまなポリシーと、TFSを実行する人々が持っているWindowsドメインとの統合がサポートされています。 Visual Studioと緊密に統合されたGUIはもう1つのセールスポイントであり、 平均未満 マウスとクリックして、開発者と彼のマネージャー。
したがって、GitとTFSを比較するのは適切な質問ではありません。実用的ではありませんが、正しい質問は、GitとTFSのVCS機能だけを比較することです。そのとき、GitはTFSを水から吹き飛ばします。ただし、深刻なチームには他のツールが必要であり、TFSが1つの目的地を提供します。
チームでTFSを使用していて、Gitを使用する場合は、「git to tfs」ブリッジを検討することをお勧めします。基本的に、コンピューターでGitを使用して日々作業を行い、変更をプッシュしたい場合はTFSサーバーにプッシュします。
そこにはカップルがいます（github上）。私は最後の場所で（別の開発者と一緒に）使用し、ある程度成功しました。見る：
長所と短所の間のいくつかの調査の後、私が関与していた会社もTFSに行くことにしました。 GITが優れたバージョン管理システムではないからではなく、TFSが提供する完全に統合されたALMソリューションにとって最も重要です。バージョン管理機能のみが重要である場合、選択はおそらくGITであった可能性があります。ただし、通常の開発者向けの急なGIT学習曲線は過小評価されていない可能性があります。
私のブログ投稿で詳細な説明を参照してください 真のクロステクノロジープラットフォームとしてのTFS 。
GitのDistributed全体は本当に素晴らしいです。ローカルロールバックやコミットオプション（ Eclipseのlocalhistory機能 ）など、シェルブセットに（現在の製品では）備わっていない機能がいくつかあります。開発者ブランチを使用してこれを軽減できますが、正直なところ、多くの開発者は分岐とマージを少し嫌います。 TFSの古いスタイルの「排他的チェックアウト」機能を何度もオンにするように頼まれました（そして、毎回それを拒否しました）。
多くの大企業は、開発者がすべての履歴をローカルワークスペースに持ち込んでそれを（たとえば新しい雇用主に）持ち込むことを非常に恐れていると思います...スナップショットを盗むことは悪いことですが、履歴全体を奪うことですさらに面倒です。 （できなかったわけではありません TFSから完全な履歴を取得します 望んでいました）...
バックアップするのに最適な方法であることが述べられています。これは、元のメンテナーが気にかけて自分のバージョンを削除する可能性があるオープンソースにとっては素晴らしいことですが、企業計画では、責任の明確な割り当てがないため、これは多くの企業にとって再び不十分ですバックアップを保持します。また、メインの「プロジェクト」が何らかの形で消えた場合、どのバージョンを使用するかを把握するのは困難です。これは、1つのリポジトリを主要/中央として指定する傾向があります。
Gitで最も気に入っているのは、プッシュ/プルオプションです。このオプションでは、コミット権を必要とせずに、プロジェクトにコードを簡単に提供できます。これを模倣するために、TFSで非常に限られたユーザーとシェルフセットを使用できると思いますが、Gitオプションほど強力ではありません。チームプロジェクト間での分岐も同様に機能する可能性がありますが、管理の観点からは、チームプロジェクトを追加すると管理上のオーバーヘッドが大きくなるため、多くの組織にとって現実的ではありません。
また、非ソース管理領域で言及されているものに追加したいと思います。作業項目の追跡、レポート、ビルドの自動化（ラボ管理を含む）などの機能は、中央の主要なリポジトリから大きな恩恵を受けます。純粋な分散モデルを使用すると、これらのノードのいずれかを先導する（したがって、分散度の低いモデルに戻る）場合を除き、これらは非常に困難になります。
TFS BasicがTFS 11に付属しているので、ローカルTFS BasicをTFS 12+時代の中央TFSに同期できる分散TFSが期待できるでしょう。 servoiceに投票してください ！
私にとって大きな違いは、TFSがソリューションに追加するすべての補助ファイル（.vssscc）がTFSを「サポート」することです-これらのファイルが間違ったブランチにマップされるという最近の問題があり、興味深いデバッグにつながります...