私は開発チームにGitを紹介しましたが、私を除いて誰もがそれを嫌っています。彼らはそれをTeamFoundationServerに置き換えたいと考えています。私はTFSにあまり詳しくありませんが、これは大きな後退のように感じます。経験のある人は、TFSでのブランチサポートをGitブランチと比較できますか？また、一般的に、TFSの長所と短所は何ですか？数年間Gitを使用した後、私はそれを嫌うつもりですか？
192445 次
9 に答える
286
私が思うに、声明は
私以外はみんな嫌い
これ以上の議論は無駄になります。Git を使い続けると、何か問題が発生した場合、彼らはあなたを責めます。
これとは別に、私にとって Git には集中型の VCS よりも優れている点が 2 つあります (一部はRob Sobersによって説明されています)。
- リポジトリ全体の自動バックアップ:誰かが中央リポジトリからプルするたびに、変更の完全な履歴を取得します。1 つのレポが失われた場合: 心配する必要はありません。すべてのワークステーションに存在するレポの 1 つを取得してください。
- オフライン レポ アクセス:自宅 (または飛行機や電車の中で) で作業しているときに、VPN 接続を開始することなく、プロジェクトのすべての履歴、すべてのチェックインを確認でき、職場にいるように作業できます。 : チェックイン、チェックアウト、ブランチ、何でも。
しかし、私が言ったように、あなたは負け戦を戦っていると思います: 誰もが Git を嫌うときは、Git を使わないでください。彼らを納得させようとするのではなく、なぜ彼らが Git を嫌うのかを知ることは、あなたの助けになるかもしれません。
彼らが単にそれを望んでおらず、それが彼らにとって新しいものであり、何か新しいことを学ぼうとしない場合: そのスタッフと一緒に開発を成功させる自信がありますか?
本当にすべての人が Git を嫌っているのでしょうか、それとも一部のオピニオン リーダーの影響を受けているのでしょうか? リーダーを見つけて、何が問題なのか尋ねてください。彼らを説得すれば、チームの他のメンバーを納得させることができます。
リーダーを説得できない場合は、Git の使用を忘れて、TFS を使用してください。あなたの人生を楽にします。
于 2010-12-11T12:24:30.057 に答える
114
2 つのシステムの主な違いは、TFS が集中型バージョン管理システムであり、Git が分散型バージョン管理システムであることです。
TFS では、リポジトリは中央サーバーに保存され、開発者は特定の時点でのコードのスナップショットである作業コピーをチェックアウトします。Git を使用すると、開発者はすべての履歴を含む リポジトリ全体を自分のマシンに複製します。
開発者のマシンに完全なリポジトリを持つ利点の 1 つは、サーバーが停止した場合の冗長性です。もう 1 つの優れた特典は、サーバーと通信することなく作業コピーをリビジョン間で前後に移動できることです。これは、サーバーがダウンしているか、単にアクセスできない場合に役立ちます。
私にとっての本当の恩恵は、サーバーと通信したり、チームに潜在的に不安定な変更を加えたり (つまり、ビルドを壊す) することなく、変更セットをローカル リポジトリにコミットできることです。
たとえば、大きな機能に取り組んでいる場合、コーディングして完全にテストするのに 1 週間かかることがあります。週の途中で不安定なコードをチェックインしてビルドを壊したくはありませんが、週の終わりに近づいていて、誤って作業コピー全体を中断してしまったらどうなりますか? ずっとコミットしていなければ、仕事を失うリスクがあります。これは効果的なバージョン管理ではなく、TFS はこの影響を受けやすくなっています。
DVCS を使用すると、変更をローカルにコミットしているため、ビルドが壊れることを心配することなく、常にコミットできます。TFS やその他の集中型システムには、ローカル チェックインの概念はありません。
DVCS の分岐とマージがどの程度優れているかについてはまだ触れていませんが、SO または Google 経由で多くの説明を見つけることができます。経験上、TFS での分岐とマージは良くないことがわかります。
あなたの組織での TFS の議論が、Git よりも Windows でうまく機能するというものであれば、Windows でうまく機能する Mercurial をお勧めします。Windows Explorer (TortoiseHg) および Visual Studio (VisualHg) との統合があります。
于 2010-12-11T04:41:39.950 に答える
87
人々は銃を下ろし、棚から離れて、少し考える必要があります。DVCS には、チームの生産性に大きな違いをもたらす、客観的かつ具体的で否定できない利点があることがわかりました。
それはすべて、分岐とマージに帰着します。
DVCS が登場する前は、「分岐やマージを行う必要がないことを神に祈ってください。そうする場合は、少なくとも非常に単純なものにしてくれるよう神に懇願してください」という指針がありました。
現在、DVCS を使用すると、分岐 (およびマージ) が大幅に改善されます。指針となる原則は、「すぐに実行できます。多くの利点が得られ、問題は発生しません」です。
そして、それはどのチームにとっても生産性を大幅に向上させます。
問題は、人々が私が今言ったことを理解し、それが真実であると確信するには、最初に少しの学習曲線に投資する必要があるということです. Git やその他の DVCS 自体を学ぶ必要はありません。Git がどのように分岐とマージを行うかを学ぶ必要があるだけです。いくつかの記事やブログの投稿を読んで再読し、ゆっくりと読み、それが見えるまで読み進めてください。それには丸 2 日か 3 日かかるかもしれません。
しかし、一度それを理解すると、非 DVCS を選択することさえ考えなくなります。DVCS には明確で客観的かつ具体的な利点があり、最大のメリットは分岐とマージの領域にあるからです。
于 2011-02-06T06:28:49.017 に答える
45
オリジナル：@Rob、TFSには「シェルビング」と呼ばれるものがあり、公式ビルドに影響を与えずに進行中の作業をコミットすることに関する懸念に対処します。中央のバージョン管理を障害と見なしていることは承知していますが、TFS に関しては、コードをシェルフにチェックインすることは強みと見なすことができ、まれに中央サーバーが進行中の作業のコピーを保持しています。ローカル マシンがクラッシュしたり、紛失または盗難にあった場合、またはすぐにギアを切り替える必要がある場合。私が言いたいのは、TFS はこの分野で適切に評価されるべきだということです。また、TFS2010 での分岐とマージは以前のバージョンから改善されており、「TFS での分岐とマージは良くないという経験から...」と言うと、どのバージョンを指しているのか明確ではありません。免責事項: 私は TFS2010 の中程度のユーザーです。
2011 年 12 月 5 日編集: OP にとって、TFS について気になることの 1 つは、作業していないときにすべてのローカル ファイルを「読み取り専用」に設定することを主張することです。変更を加えたい場合は、ファイルを「チェックアウト」する必要があります。これにより、ファイルの読み取り専用属性がクリアされ、TFS がファイルを監視するようになります。それは不便なワークフローです。私がそれを機能させる方法は、変更を加えたかどうかを自動的に検出し、ファイル属性をまったく気にしたり気にしたりしないことです。そうすれば、Visual Studio、メモ帳、または任意のツールを使用してファイルを変更できます。この点で、バージョン管理システムは可能な限り透過的でなければなりません。Windows Explorer Extension ( TFS PowerTools) を使用すると、Windows エクスプローラーでファイルを操作できますが、ワークフローはあまり単純化されません。
于 2011-02-04T02:53:05.023 に答える
17
言われたすべてに加えて（
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 つの目的地を提供する場所です。
于 2012-03-20T21:48:23.060 に答える
16
チームが TFS を使用していて、Git を使用したい場合は、"git to tfs" ブリッジを検討することをお勧めします。基本的に、コンピューターで Git を使用して毎日作業し、変更をプッシュする場合は、それらを TFS サーバーにプッシュします。
そこにはいくつかあります（github上）。私は最後の場所で（別の開発者と一緒に）1つを使用して、ある程度成功しました。見る：
于 2012-06-19T15:55:14.050 に答える
14
賛否両論を検討した結果、私が関わった会社もTFSを採用することに決めました。GIT が優れたバージョン管理システムではないからではなく、TFS が提供する完全に統合された ALM ソリューションにとって最も重要なことです。バージョン管理機能だけが重要な場合、GIT が選択された可能性があります。ただし、通常の開発者の急な GIT 学習曲線を過小評価することはできません。
私のブログ投稿TFS as a true cross-technology platformで詳細な説明を参照してください。
于 2012-03-21T23:16:28.873 に答える
13
Git の Distributed 全体は本当に素晴らしいものです。ローカル ロールバックやコミット オプション ( Eclipse の localhistory 機能など) など、(現在の製品では) シェルブセットにはないいくつかの機能を提供します。開発者ブランチを使用してこれを軽減できますが、正直なところ、多くの開発者はブランチとマージを少しでも好まないのです。私は、TFS の古いスタイルの「排他的チェックアウト」機能を何度かオンにするように求められました (そして毎回拒否されました)。
多くの大企業は、開発者が履歴全体をローカルのワークスペースに持ち込んで、それを (たとえば、新しい雇用主に) 持ち込むことを許可することを非常に恐れていると思います... スナップショットを盗むのは悪いことですが、履歴全体を奪うことはできません。はさらに面倒です。(必要なTFSから完全な履歴を取得できなかったわけではありません)...
これはバックアップするための優れた方法であると述べられています。これは、元のメンテナーが気にするのをやめて自分のバージョンを削除する可能性があるオープンソースには最適ですが、エンタープライズプランの場合、責任の明確な割り当てがないため、これも多くの企業にとって不十分ですバックアップを保持します。また、メインの「プロジェクト」が何らかの形で消滅した場合、どのバージョンを使用するかを判断するのは困難です。これは、1 つのリポジトリを主要/中央として指定する傾向があります。
Git で私が最も気に入っているのは、プッシュ/プル オプションです。これにより、コミット権限がなくてもプロジェクトにコードを簡単に提供できます。TFS で非常に限られたユーザーとシェルフセットを使用してこれを模倣できると思いますが、Git オプションほど強力ではありません。チーム プロジェクト間の分岐も同様に機能する可能性がありますが、チーム プロジェクトを追加すると多くの管理オーバーヘッドが追加されるため、管理の観点からは、多くの組織にとって現実的ではありません。
また、非ソース管理領域で言及されていることにも追加したいと思います。作業項目の追跡、レポート作成、ビルドの自動化 (ラボ管理を含む) などの機能は、主要な中央リポジトリから大きな恩恵を受けます。これらは、純粋な分散モデルを使用すると、ノードの 1 つを先行させない限り (したがって、分散の少ないモデルに戻らない限り)、はるかに難しくなります。
TFS 11 に付属する TFS Basic では、TFS 12 以降の時代に、ローカルの TFS Basic を中央の TFS に同期できるようにする分散 TFS が期待される日も遠くないかもしれません。私はそれに対する私の投票を uservoice に入れます!
于 2012-03-21T15:39:39.387 に答える
9
私にとっての主な違いは、TFS が TFS を「サポート」するためにソリューション (.vssscc) に追加するすべての補助ファイルです。最近、これらのファイルが間違ったブランチにマップされてしまうという問題があり、興味深いデバッグにつながりました。 ...
于 2011-05-05T14:10:18.273 に答える