0

小さなチームを CVS/SVN から git に移行することを正当化するよう求められました。

これまでのところ、私の読書から、次の 3 つの主なメリットを特定できます。

  • スピード
  • 簡単な分岐
  • 分散
  • SVN が提供しないその他の機能 (部分的なファイルのコミット、ステージングなど...)

スピード

その速度のために git を支持するいくつかの議論がありますが、Git の優れた速度について言及することに対する一般的な反応は、3 秒と 13 秒の違いは無視できるというものです。

実際の例:

日中はたくさんの仕事をして、夕方に家に帰る前に安定したものをコミットします。
数百のファイルを追加し、既存のファイルを変更、移動、リファクタリングした大きなコミットでは、コートを着て机を片付ける前に、CVS がコミットを実行します。これは git とどう違うのでしょうか?

簡単な分岐

Git のブランチ機能は、その強力な機能の 1 つとして多くの人に称賛されています。ただし、CVS/SVN での分岐は多くのエンジニアにとって十分であるように思われます。特に最新の IDE では、どの RCS が実際に使用されているかに関係なく、全体のエクスペリエンスとワークフローがほぼ同じになります。

アイデアを試してみたいときは、Eclipse で自分のプロジェクト ノードを右クリックし、[別のブランチに切り替える] を選択して [新規] を選択し、名前を入力して、「メインラインを汚染する」ことなくコミットして更新します。 CVS らしいです。このブランチの新しいアイデアが安定していて良いと判断したら、プロジェクトをもう一度右クリックし、「別のブランチまたはバージョンとマージする」を選択し、HEAD を選択します。HEAD に戻りますが、作業の変更が実装されています... 方法gitは私の経験を改善しますか?

真の分散

分散型 RCS を使用する主な利点は、災害復旧にあるようです。ただし、同様のプロパティは CVS と SVN にも固有のものです。これは特に、標準的なプラクティスの使用法に当てはまります。

今では、朝起きて最初にすることの標準的な方法は、夜間に行われた変更がないかリポジトリをチェックし、必要に応じて更新/マージを行うことだと考えています。朝の地面、私は失われただろう...まあ...何もない。私は新しいリポジトリを作成し、私のローカル ファイルをサーバーにコミットします。他の 5 人の従業員も同じことを行います。マージの手間が少しかかるかもしれませんが、ローカルの変更をコミットしていた場合よりも多くはありません。すでに存在するサーバーであり、私たちは再び離れています。大きな問題ではない。

GIT ステージング

よく言及されるもう 1 つの機能は、ステージング エリアです。これは SVN/CVS に相当するものはなく、開発者が「自分のコミットを作成」して、必要なファイルに含めることができます。 

多くの場合、これについて言及するとき、私は単純にチェンジセットを思い浮かべます。ステージングエリアはどのように異なりますか?

実際、Git の使用にはいくつかの欠点があります。

  • ローカル コミットは、コードを失う可能性が高いことを意味します。私の開発マシンは SVN サーバーよりもはるかに脆弱であり、共通リポジトリにプッシュする前に作業が危険にさらされるからです。
  • ほとんどの開発者はオフラインでプロジェクトに取り組むことはないため、オフラインでの作業には目に見える利点はありません。

git に関する基本的なことを見逃しているか誤解しているように感じ、スイッチのビジネス ケースを正当化するのに苦労しています。関連する問題の理解を深めるために、特に git が単純に段階的に優れたソリューションではなく、CVS/SVN よりも根本的に優れたソリューションになる具体的なユースケースを特定できる場合は、ご意見をいただければ幸いです。

4

2 に答える 2

5

高レベルのポイントを正面から狙うには:

  1. ケーキのアイシングはスピード
  2. 人々が「簡単な分岐」と言うとき、実際には「簡単なマージ」を意味します。CVS は実際にはマージを行いません。Subversion の開発者は、CVS のマージへのアプローチがくだらないことを認めており、その方法を維持しています。
  3. ステージング、部分的なファイルのコミットなど。これらは、Git がマージをサポートする方法の結果である便利な機能です。繰り返しますが、それ自体が「コア」の利点とは考えていません。

本当の利点を理解するために、Git を使用すると、コードの断片を前後に処理するメカニズムをいじる必要がなくなり、必要なコードをどこに置くかに集中できるようになります。これは、安定したカーネル バージョンの開発と、さまざまな長寿命の機能ブランチによって実証されています。開発者にとって大変な作業は、組み込むコードを決定することです。その決定が下されると、そうする機械的なプロセスはコンピューターによって処理されます。

複数のブランチを持つ CVS では問題があり、Git では簡単なことの 1 つは、バグを修正するか、複数のブランチに他の変更を反映させることです。メインラインまたは 1 つの顧客ブランチで変更を行ったとします。いくつかの QA とフィールド テストの後、他の 3 つの顧客ブランチにも修正を適用する必要があると判断しました。CVS では、それは次のようなプロセスです。

  1. cvs logバグを修正するリビジョン AB を特定する固定ブランチ
  2. cvs diff -rA:B > bugfix.patch変更を保存して再適用できるようにする
  3. cvs update別の支店へ
  4. patch -p1 -i bugfix.patch変更を適用するには
  5. cvs commit変更を記録します。
  6. 修正するブランチごとに手順 3 ～ 5 を繰り返します。

手順 4 と 5 は、特にマージの競合がある場合にエラーが発生しやすくなります。あなたが非常に訓練されていない限り、バグ修正が最初に行われた場所の記録や、それを他のブランチに簡単に関連付けることができるものはありません。ステップ 1、2、3、および 5 はすべて、Git に慣れている人にとっては、サーバーとの通信が非常に遅いことに注意してください。

対照的に、Git では:

  1. git logバグを修正するリビジョン C を識別する修正済みブランチ
  2. git checkout修正するブランチ
  3. git cherry-pick C修正を適用します。
  4. 修正するブランチごとに手順 2 と 3 を繰り返します。
  5. git push

チェリー ピック ステップでは、バグ修正がどのコミットから来たかがコミット メッセージに記録されるため、後で簡単に見つけることができます。マージの競合がある場合は、最初にそれらを解決する必要がありますが、Git の 'rerere' (REpeat REmembered REsolution) は、それが同じ競合である場合、その後はそれを自動化し、ミスの可能性を回避します。このプロセスのステップ 5 だけがサーバーとの対話を伴いますが、Git はネットワーク経由で送信する必要がある最小限のデータを正確に認識しているため、非常に高速です。

新機能の開発では、Git がさらに強力な機能を提供します。進行中の作業で他の人を台無しにする危険を冒すことなく、ブランチで作業を行うことができます。それが完了したら、そのブランチを好きな場所にマージします。これは、CVS や SVN しか使用したことのない人には理解できない Git の真の力です。git merge実際に機能し、非常にうまく機能します。その機能が複数のブランチに必要な場合は、それらのそれぞれにマージできます。履歴には、すべてがその 1 つの機能ブランチから派生したことが正確に反映されます。

于 2012-04-19T14:36:54.713 に答える
2

gitを十分に長く使用していると、実際にはもっと便利であることに気付くでしょう。私はCVSの経験はありませんが、SVN（「CVSは正しく行われる」をモットーにしています）を経験しました。

まず第一に、Gitの分散型の性質は確かに祝福です。作業を別のリポジトリ（GitHubなど）にプッシュしないと1週間作業できないため、コンピューターに何かが起こっても作業が実際に失われることはありません。

「私のレポが死んだら、別のレポを作成する」とあなたが言ったことには、1つの問題があります。あなたはすべての歴史を失います！これは、以前のコミット、リリースなどがすべてなくなったことを意味します。思ったほど快適ではありません。

また、あなたは1日に1回コミットしますが、私たちの多くは1日に多くのコミットを実行します。実際、多くの小さなコミットははるかに管理しやすく、エラーが発生した場合に元に戻すのが簡単です。Gitを使用すると、すべてのコミットが高速になります。Svnを使用すると、それらすべてがネットワークとsshを通過しますが、これにはもう少し時間がかかります。

一元化されたリポジトリではそれほど便利ではないものが他にもあります。たとえば、バージョン管理されたものとバージョン管理されていないもののディレクトリがある場合、Gitで名前を変更するのは簡単です。svnで名前を変更するには、バージョン管理されていないファイルを誤ってバージョン管理しないように、リポジトリのアドレス全体（2回）を書き込む必要があります。そして、それは常にコミットが付属しています。いくつかのディレクトリを再編成する場合、無駄なコミットがいくつもあります。

SVNでは、いくつかのファイルを追加してコミットしてから、を実行するとsvn ls、新しいファイルが表示されなくなりますsvn update。しかし、Gitでは、リポジトリを所有しているので、そのようなことは必要ありません。

結局、それらはすべて機能するので、大きな欠陥を見つけることができないので、別の場所に移動することができます。ただし、これは利便性の問題です（少なくとも私にとっては）。もちろん、Windows用にプログラムすれば、すべてを行うことができますが、Linuxで同じことを行うと、多くのことがより理にかなっているため、はるかに気分が良くなります。私が言ったように、それらはすべて機能しますが、いくつかはより良いデザインを持っています。それはGitとCVSまたはSVNの場合だと思います。

私の提案は、Gitを試してみることです。しばらくの間それを使ってください。さまざまな機能を試してみてください。数か月以内に、Gitの方が好きかCVSが好きかという結論に達します。

于 2012-04-19T14:00:12.910 に答える