Git vs Team Foundation Server [終了]

私は開発チームにGitを紹介しましたが、私を除いて誰もがGitを嫌っています。彼らはそれをTeam Foundation Serverに置き換えたいと考えています。TFSについてはあまり詳しくありませんが、これは大きな後退のように感じます。経験のある人がTFSのブランチサポートをGitブランチと比較できますか？また、一般的に、TFSの長所と短所は何ですか？Gitを数年間使用した後、私はそれを嫌うでしょうか？

私は思う

私以外はみんな嫌い

これ以上の議論は無駄になります。Gitを使い続けると、何か問題があった場合に非難されます。

これとは別に、私にとってGitには、（Rob Sobersによって部分的に説明されているように）最も評価されている集中型VCSよりも2つの利点があります。

• リポジトリ全体の自動バックアップ：誰かが中央リポジトリからプルするたびに、変更の完全な履歴を取得します。1つのリポジトリが失われた場合：心配しないで、すべてのワークステーションに存在するリポジトリの1つを取ってください。
• オフラインレポアクセス：私は自宅で働いているとき（あるいは飛行機や電車の中で）、私は仕事に私のVPN接続を起動せずに、プロジェクト、ひとつひとつチェックインの完全な履歴を見ることができると私は同じように動作することができなかった仕事で：チェックイン、チェックアウト、ブランチ、何でも。

しかし、私が言ったように：あなたは負けた戦いを戦っていると思います：誰もがGitを嫌うときはGitを使わないでください。説得しようとするのではなく、なぜGitが嫌いなのかを知るのに役立ちます。

彼らが単にそれを望まないのは、それが彼らにとって新しいものであり、何か新しいことを学ぶ気がない場合です。そのスタッフと一緒に開発を成功させることを確信していますか？

本当に一人一人がGitを嫌いですか、それとも彼らはオピニオンリーダーの影響を受けていますか？リーダーを見つけて、何が問題なのか尋ねてください。それらを納得させれば、あなたはチームの残りを納得させるでしょう。

リーダーを説得できない場合は、Gitの使用を忘れて、TFSを使用してください。あなたの人生を楽にします。

2つのシステムの主な違いは、TFSが集中型バージョン管理システムであり、Gitが分散型バージョン管理システムであることです。

TFSを使用すると、リポジトリは中央サーバーに保存され、開発者は特定の時点でのコードのスナップショットである作業コピーをチェックアウトします。Gitを使用すると、開発者はすべての履歴を含め、リポジトリ全体を自分のマシンに複製します。

完全なリポジトリを開発者のマシンに置くことの1つの利点は、サーバーが停止した場合の冗長性です。もう1つの優れた点は、サーバーと通信せずに作業コピーをリビジョン間で移動できることです。これは、サーバーがダウンしているか、単に到達できない場合に役立ちます。

私にとって本当の恩恵は、サーバーと通信したり、チームに不安定な可能性のある変更を加えたりすることなく（つまり、ビルドを壊すことなく）、変更セットをローカルリポジトリにコミットできることです。

たとえば、大きな機能に取り組んでいる場合、コーディングして完全にテストするのに1週間かかることがあります。週の半ばに不安定なコードをチェックインしてビルドを中断したくありませんが、週末の終わりに近づいていて、作業コピー全体を誤ってボークした場合はどうなりますか？私がずっとコミットしていなかったら、自分の仕事を失うリスクを負っています。これは効果的なバージョン管理ではなく、TFSはこれの影響を受けやすくなっています。

DVCSを使用すると、ローカルで変更をコミットするため、ビルドの中断を心配することなく、常にコミットできます。TFSおよびその他の集中型システムでは、ローカルチェックインの概念はありません。

私はDVCSでの分岐とマージがどれほど優れているかについても調べていませんが、SOやGoogleを介してここでたくさんの説明を見つけることができます。経験から、TFSでの分岐とマージは適切ではないことがわかります。

組織でのTFSの議論が、GitよりもWindowsでうまく機能するということであれば、Windowsでうまく機能するMercurialをお勧めします。Windowsエクスプローラー（TortoiseHg）およびVisual Studio（VisualHg）との統合があります。

人々は銃を下ろし、棚から離れ、少し考えなければなりません。チームの生産性に大きな違いをもたらすDVCSには、客観的で具体的で否定できない利点があることがわかりました。

それはすべて分岐とマージに帰着します。

DVCSの前の指針となる原則は、「分岐やマージに入る必要がないことを神に祈ります。そうする場合は、少なくとも非常に単純なことを彼にお願いしてください」でした。

現在、DVCSを使用すると、分岐（およびマージ）が大幅に改善されます。基本的な原則は、「帽子をかぶるだけで実行できます。これにより、多くの利点が得られ、問題が発生することはありません。」

そして、それはどんなチームにとっても巨大な生産性ブースターです。

問題は、私が今言ったことを理解し、それが真実であると確信するためには、まず学習曲線に少し投資する必要があるということです。彼らはGitや他のDVCS自体を学ぶ必要はありません... Gitがどのように分岐とマージを行うかを学ぶ必要があるだけです。記事やブログの投稿を読んだり、読み直したりします。時間がかかり、表示されるまで作業を続けます。それは丸2日か3日のうちの良い部分を取るかもしれません。

しかし、それを見ると、非DVCSを選択することさえ考慮しません。DVCSには明確で客観的で具体的な利点があり、最大のメリットは分岐とマージの分野にあるからです。

オリジナル：@Rob、TFSは「と呼ばれるものがある棚それが公式のビルドに影響を与えることなく、作業中のコミットについてのあなたの懸念に対処し」。セントラルバージョンコントロールは邪魔だと思いますが、TFSに関しては、コードをシェルフにチェックインすることは、強みとして見なすことができます。そうすると、セントラルサーバーは、まれに進行中の作業のコピーを保持します。ローカルマシンがクラッシュしたり、紛失/盗難に遭ったり、ギアをすばやく切り替えたりする必要がある。私のポイントは、TFSがこの分野で適切に賞賛されるべきだということです。また、TFS2010での分岐とマージは以前のバージョンから改善されており、「経験から、TFSでの分岐とマージは好ましくない」と言ったときに、どのバージョンを参照しているかは明確ではありません。免責事項：私はTFS2010の適度なユーザーです。

Edit Dec-5-2011：OPにとって、TFSについて私が気にかけることの1つは、作業していないときに、すべてのローカルファイルを「読み取り専用」に設定することを主張することです。変更を加えたい場合の流れは、ファイルを「チェックアウト」する必要があることです。これにより、ファイルの読み取り専用属性がクリアされ、TFSがそれを監視できるようになります。これは不便なワークフローです。私がそれを機能させることを好む方法は、私が変更を加えたかどうかを自動的に検出し、ファイル属性をまったく気にしない/気にすることです。そうすれば、Visual Studio、メモ帳、または好きなツールでファイルを変更できます。この点で、バージョン管理システムは可能な限り透過的である必要があります。Windowsエクスプローラー拡張機能（TFS PowerTools）Windowsエクスプローラーでファイルを操作できますが、ワークフローはそれほど単純化されません。

言われているすべての上に（

https://stackoverflow.com/a/4416666/172109

https://stackoverflow.com/a/4894099/172109

https://stackoverflow.com/a/4415234/172109

）、正解です。TFSは単なるVCSではありません。TFSが提供する主要な機能の1つは、ネイティブに統合されたバグ追跡機能です。変更セットは問題にリンクされており、追跡できます。チェックインのさまざまなポリシーがサポートされているだけでなく、TFSを実行するユーザーが持っているWindowsドメインとの統合もサポートされています。GUIとVisual Studioが緊密に統合されていることも、平均的なマウスアンドクリックの開発者とその管理者にとって魅力的です。

したがって、GitとTFSを比較することは適切な質問ではありません。正解ですが、実用的ではありませんが、GitをTFSのVCS機能だけと比較することが問題です。そのとき、GitはTFSを水から吹き飛ばします。ただし、深刻なチームには他のツールが必要であり、これがTFSが1つの目的地を提供する場所です。

チームがTFSを使用していて、Gitを使用したい場合は、「git to tfs」ブリッジを検討することをお勧めします。基本的に、コンピューターでGitを使用して毎日作業し、変更をプッシュしたい場合は、TFSサーバーにプッシュします。

そこには（github上に）いくつかあります。私は最後の場所で（別の開発者と共に）使用し、ある程度の成功を収めました。見る：

https://github.com/spraints/git-tfs

https://github.com/git-tfs/git-tfs

長所と短所の間でいくつかの調査の後、私が関わっていた会社もTFSに行くことにしました。GITは優れたバージョン管理システムではないためではありませんが、最も重要なのは、TFSが提供する完全に統合されたALMソリューションにとって重要です。バージョン管理機能のみが重要である場合、おそらくGITを選択した可能性があります。ただし、通常の開発者にとってのGITの急な学習曲線は過小評価されない場合があります。

真のクロステクノロジープラットフォームとしての私のブログ投稿TFSの詳細な説明を参照してください。

GitのDistributed全体は本当に素晴らしいです。ローカルロールバックやコミットオプション（Eclipseのlocalhistory機能など）など、シェルブセットにはない（現在の製品では）いくつかの機能を提供します。開発者のブランチを使用してこれを軽減することもできますが、正直に言うと、多くの開発者は1つのブランチをブランチしてマージすることを好みません。TFSの古いスタイルの「排他的チェックアウト」機能を何度もオンにするように求められました（何度も拒否されました）。

多くの大企業は、開発者が履歴全体をローカルのワークスペースに持ち込み、それを（たとえば、新しい雇用者に）持ち込むことを非常に怖がっていると思います...スナップショットを盗むのは悪いことですが、履歴全体を奪いますさらに面倒です。（TFSから完全な履歴を取得できなかったわけではありません）...

これは、バックアップするのに最適な方法であると述べられています。これは、元のメンテナーが彼のバージョンを気にして削除する可能性があるオープンソースにとっても素晴らしいですが、企業計画では、責任の明確な割り当てがないため、これは多くの企業にとって再び不十分です。バックアップを保持します。また、メインの「プロジェクト」が何らかの理由で消えた場合、どのバージョンを使用するかを判断するのは困難です。1つのリポジトリをリーディング/セントラルとして指定する傾向があります。

私がGitで最も気に入っているのは、プッシュ/プルオプションです。このオプションでは、コミット権を必要とせずに、プロジェクトにコードを簡単に提供できます。TFSで非常に限られたユーザーとシェルベセットを使用してこれを模倣できると思いますが、Gitオプションほど強力ではありません。チームプロジェクト間での分岐も同様に機能する可能性がありますが、チームプロジェクトを追加すると管理上のオーバーヘッドが大幅に増加するため、管理の観点からは、多くの組織にとって実際には現実的ではありません。

また、ソース管理以外の領域で言及されていることを追加したいと思います。作業項目の追跡、レポート、ビルドの自動化（ラボ管理を含む）などの機能は、主要な主要リポジトリから大きなメリットを得ます。純粋な分散モデルを使用する場合、ノードの1つを先行させる（したがって、分散度の低いモデルに戻る）場合を除き、これらは非常に困難になります。

TFS BasicがTFS 11に付属しているので、ローカルTFS BasicをTFS 12+時代の中央TFSに同期できる分散TFSを期待することは遠くないかもしれません。私はそのための投票をuservoiceに記入します！

私にとっての主な違いは、TFSがソリューションに追加するすべての補助的なファイル（.vssscc）がTFSを「サポート」することです。これらのファイルが誤ったブランチにマッピングされてしまうという最近の問題があり、興味深いデバッグにつながりました...