21

何千もの同様のトピックが浮かんでいることを私は知っています。SO で少なくとも 5 つのスレッドを読みましたが、それでも DVCS について確信が持てないのはなぜですか?

以下の質問しかありません (勝手に Java プロジェクトだけを心配していることに注意してください)。

  • ローカルでコミットすることの利点または価値は何ですか? 何?本当?最新のすべての IDE で、変更を追跡できますか? 必要に応じて、特定の変更を復元できます。また、IDE レベルで変更/バージョンにラベルを付ける機能もあります!?
  • ハードドライブをクラッシュさせたらどうなりますか? 私のローカルリポジトリはどこに行きましたか? (では、中央レポにチェックインするのと比べて、どのようにクールなのですか?)
  • オフラインまたは飛行機での作業。重要なことは何ですか?変更を加えてリリースをビルドするには、最終的に中央リポジトリに接続する必要があります。それまでは、自分の変更をローカルで追跡する方法は問題ではありません。
  • わかりました Linus Torvalds は Git に人生を捧げ、それ以外はすべて嫌いです。それはやみくもに賛美を歌うのに十分ですか?Linus は、私の中規模プロジェクトのオフショア開発者とは違う世界に住んでいますか?

私を売り込む!

4

10 に答える 10

14

私はあなたが今いる場所にいて、分散バージョン管理の使用に懐疑的です。私はすべての記事を読み、理論的な議論を知っていましたが、確信が持てませんでした。

ある日、入力git initしていると突然 git リポジトリ内にいることに気づきました。

同じことをすることをお勧めします - ただ試してみてください。コツをつかむために、小さな趣味のプロジェクトから始めましょう。次に、より大きなものに使用する価値があるかどうかを判断します。

于 2010-04-03T10:07:42.603 に答える
13

信頼性

ハードディスクが静かにデータを破損し始めたら、それについて知りたいと思うでしょう。Git は、コミットしたすべての SHA1 ハッシュを取得します。SVN を使用した中央レポが 1 つあり、そのビットが障害のある HDD コントローラーによって静かに変更された場合、手遅れになるまでそれを知ることはできません。

そして、あなたは 1 つの中央リポジトリを持っているので、唯一のライフラインを吹き飛ばしただけです。

git を使用すると、誰もが変更履歴を備えた同一のリポジトリを持ち、完全なイメージの SHA1 により、そのコンテンツを完全に信頼できます。そのため、HEAD の 20 バイトの SHA1 をバックアップすると、信頼できないミラーからクローンを作成したときに、失ったものとまったく同じリポジトリを持っていることを確信できます!

分岐 (および名前空間の汚染)

一元化されたレポを使用すると、すべてのブランチが世界中に表示されます。プライベート ブランチを作成することはできません。他のグローバル名とまだ衝突していないブランチを作成する必要があります。

test123――いまいましい、すでに があり test123ます。試してみましょうtest124。」

そして、誰もがばかげた名前を持つこれらすべてのブランチを確認する必要があります。「本当に必要な場合を除き、ブランチを作成しない」という会社のポリシーに屈する必要があり、git で得られる多くの自由が妨げられます。

コミットと同じ。コミットするときは、コードが確実に機能することを確認してください。そうしないと、ビルドが壊れます。中間コミットはありません。それらはすべて中央リポジトリに移動するからです。

git を使用すると、このナンセンスはまったくありません。必要に応じてローカルでブランチとコミットを行います。変更を世界中に公開する準備ができたら、変更をプルするように依頼するか、「メイン」の git リポジトリにプッシュします。

パフォーマンス

リポジトリはローカルであるため、すべての VCS 操作は高速であり、ラウンド トリップや中央サーバーからの転送は必要ありません。git log変更履歴を見つけるためにネットワークを経由する必要はありません。SVNはそうです。重要なものはすべて1 つの場所に保存されるため、他のすべてのコマンドと同じです。

SVNに対するこれらの利点やその他の利点については、Linus の講演をご覧ください。

于 2010-04-03T09:40:33.127 に答える
10

私はMercurialの開発者で、Mercurial のコンサルタントとして働いてきました。ですから、あなたの質問は非常に興味深いと思います。

  • ローカルでコミットすることの利点または価値は何ですか? [...]

最近のIDEは、単純な元に戻す/やり直しを超えてローカルの変更を追跡できることは間違いありません。ただし、これらのファイル スナップショットと完全なバージョン管理システムの間には、まだ機能上のギャップがあります。

ローカル コミットでは、レビューのために送信する前に、ローカルで「ストーリー」を準備するオプションが提供されます。私はよく、2 ~ 5 件のコミットを伴ういくつかの変更に取り組んでいます。コミット 4 を作成した後、戻ってコミット 2 を少し修正する可能性があります (コミット 4 を作成した後にコミット 2 でエラーが発生した可能性があります)。そうすれば、最新のコードだけでなく、最後のいくつかのコミットにも取り組むことができます。すべてがローカルである場合、それは簡単に可能ですが、中央サーバーと同期する必要がある場合は、よりトリッキーになります.

  • ハードドライブをクラッシュさせたらどうなりますか? [...] では、中央レポにチェックインするのと比べて、どのようにクールなのでしょうか?

全然かっこよくない!:-)

ただし、中央リポジトリを使用しても、作業コピー内のコミットされていないデータについて心配する必要があります。したがって、とにかくバックアップソリューションを用意する必要があると主張します.

私の経験では、多くの場合、コミットされていないデータの大きな塊が集中型システムの作業コピーに横たわっています。クライアントは、開発者に少なくとも週に 1 回コミットするよう説得しようとしている方法を教えてくれました。

多くの場合、次の理由により、変更がコミットされないままになります。

  1. 彼らは本当に終わっていません。コードに debug print ステートメントが含まれていたり、不完全な関数が含まれていたりする可能性があります。

  2. コミットすることは集中型システムtrunkでは危険です。他のすべての人に影響を与えるからです。

  3. コミットするには、最初に中央リポジトリとマージする必要があります。コードに他の競合する変更が加えられていることがわかっている場合、そのマージは威圧的かもしれません。変更がすべて完了していない可能性があり、既知の良好な状態から作業することを好むため、マージは単純に煩わしい場合があります。

  4. 過負荷の中央サーバーと通信する必要がある場合、コミットが遅くなる可能性があります。オフショアの場所にいる場合、コミットはさらに遅くなります。

上記が実際には集中型バージョン管理と分散型バージョン管理の問題ではないと思うなら、あなたは絶対に正しいです。CVCS を使用すると、人々は別々のブランチで作業できるため、上記の 2 と 3 を簡単に回避できます。別の使い捨てブランチを使用すると、より洗練された変更をコミットする別のブランチを作成できるため、好きなだけコミットすることもできます (解決 1)。ただし、コミットはまだ遅くなる可能性があるため、4 は適用できます。

DVCS を使用する人は、貧乏人のバックアップ ソリューションとして、「ローカル」コミットをリモート サーバーにプッシュすることがよくあります。チームの他のメンバーが作業しているメイン サーバーではなく、別の (場合によってはプライベートな) サーバーにプッシュします。そうすれば、彼らは分離して作業し、オフサイトのバックアップを保持できます.

  • オフラインまたは飛行機での作業。[...]

ええ、私もその議論が好きではありませんでした。私は 99% の時間、良好なインターネット接続を使用しており、これが問題になるほど十分に飛行していません :-)

ただし、本当の議論は、オフラインであるということではなく、オフラインのふりをすることができるということです。より正確には、変更を中央リポジトリにすぐに送信する必要なく、分離して作業できることです。

DVCS ツールは、人々がオフラインで作業している可能性があるという考えに基づいて設計されています。これには多くの重要な結果があります。

  • ブランチのマージは自然なことになります。人が並行して作業できるようになると、当然コミット グラフにフォークが発生します。したがって、これらのツールはブランチのマージに非常に優れている必要があります。SVNのようなツールは、マージがあまり得意ではありません

    Git、Mercurial、およびその他の DVCS ツールは、分散されているから直接ではなく、この分野でより多くのテストを行っているため、よりよくマージされます。

  • より柔軟に。DVCS を使用すると、任意のリポジトリ間で変更を自由にプッシュ/プルできます。実際の中央サーバーを使用せずに、自宅と職場のコンピューター間でプッシュ/プルを行うことがよくあります。公開の準備ができたら、Bitbucket のような場所にプッシュします。

    マルチサイト同期は「エンタープライズ機能」ではなく、組み込み機能です。そのため、オフショアの場所がある場合、彼らはローカル ハブ リポジトリをセットアップし、これを相互に使用できます。その後、ローカル ハブの時間、毎日、または都合の良いときに同期できます。これには、定期的に実行さhg pullれるcronjob だけが必要です。git fetch

  • クライアント側のロジックが増えるため、スケーラビリティが向上します。これは、中央サーバーのメンテナンスが少なくなり、クライアント側のツールがより強力になることを意味します。

    DVCS を使用すると、(コミット メッセージだけでなく)コードのリビジョンを通じてキーワード検索を実行できると期待しています。一元化されたツールでは、通常、追加のインデックス作成ツールをセットアップする必要があります。

于 2014-04-12T10:49:42.153 に答える
6

DVCS は私にとって非常に興味深いものです。

  • は、ソース管理プロセスにまったく新しい次元を追加します:パブリケーションです。マージ ワークフロー
    だけでなく、公開ワークフロー (どのリポジトリにプッシュ/プルするか) もあり、それには次の点で多くの意味があります。

    • 開発ライフサイクル (デプロイメント目的で、製品にリリースするために作成されたものなど、特定のタイプのコミット用にのみ作成されたリポジトリを使用)
    • ソロ タスク (1 つのファイルの形式であっても、バックアップ リポジトリをプッシュおよび更新できます)
    • 相互依存関係プロジェクト (プロジェクト A のチームが、チーム プロジェクト B が最終的に中央リポジトリにコミットするのを待っているとき、B に中間開発をメールで添付の zip ファイルとして「渡す」よう依頼することがあります。 A がしなければならないことは、B リポジトリを潜在的なリモートとして追加し、それを取得して覗くことです)
  • リビジョンを生成/消費する新しい方法をもたらします:

    • 新しいリビジョンを生成する受動的な方法(レポから積極的に引っ張ってきたものだけがブランチでそれらを見ることができます)
    • 他の人からのリビジョンを積極的に使用する方法(リポジトリをリモートとして追加し、必要なものを取得/マージすることにより)。

つまり、他の人が作業を中央リポジトリに配信することに依存するのではなく、さまざまなアクターやそのリポジトリとより直接的な関係を持つことができるということです。

于 2010-04-01T21:50:15.653 に答える
2

IDEがあなたのために追跡を行っているというあなたの中心的な議論は誤りです。実際、ほとんどの IDE には、無制限の取り消しレベル以外にそのような機能はありません。ブランチ、マージ、リバート、コミット メッセージ (ログ) などを考えてみると、あなたが参照した IDE でさえ不十分であるに違いありません。特に、コミットを追跡することは疑いがあります-おそらくあなたが取り組んでいるいくつかの異なるブランチで-オンラインになったら、それらをリポジトリに適切にプッシュします。

あなたのIDEが実際にそれをすべて行うなら、私はそれ自体を分散バージョン管理システムと呼んでいます。

最後に、何らかの理由で中央リポジトリが停止した場合 (サービス プロバイダーが破産した、火災が発生した、ハッカーが破損したなど)、最近リポジトリをプルしたすべてのマシンに完全なバックアップがあります。

編集: DVCS は中央リポジトリと同じように使用できます。少なくとも中小規模のプロジェクトでは、そうすることをお勧めします。常にオンラインになっている中央の「信頼できる」リポジトリを 1 つ持つことで、多くのことが簡素化されます。そのマシンがクラッシュした場合、サーバーが修復されるまで、一時的に別のマシンのいずれかに切り替えることができます。

于 2010-04-01T21:49:52.643 に答える
1

興味深い質問です。

私は DVCS の経験豊富なユーザーではありませんが、限られた露出で非常にポジティブに感じています。

2ステップコミットできるのが大好きです。それは私に合っています。

心に浮かぶいくつかの利点:

  1. より良いマージのサポート。Branch-Merge は DVCS の第 1 級市民のように感じられますが、集中型ソリューションの私の経験では、それは苦痛でトリッキーであることがわかりました。マージ トラッキングが svn で利用できるようになりましたが、それでも遅くて面倒です。

  2. 大規模なチーム。DVCS は、シングル ユーザー コミット専用ではありません。マスター リポジトリにコントリビュートする (またはコントリビュートしない) 前に、チーム間でコミットをプッシュおよびプルできます。これは、特定の種類のコラボレーションにとって非常に貴重です。

  3. 実験的な機能に取り組んでいるとき、頻繁にコミットすることは理にかなっていますが、それは短期的なものに限られます。常にメインのコードベースを分岐させたくないので、再生と再記録ができると便利です。同様に、継続的インテグレーションを使用する場合にも役立つことがわかります。リファクタリング作業に何日も取り組んでいると、容認できない時間枠でビルドが壊れる可能性がありますが、それでも変更を追跡したいと考えています。

私の DVCS の経験は、Git よりも Mercurial の方が多いことに注意してください。CVS/SVN のバックグラウンドを持っているので、Mercurial (Hg) を使用すると学習曲線がはるかに簡単になることがわかりました。最近追加された Mercurial の Google Code サポートも恩恵です。... Git に対する私の最初の反応は否定的でしたが、DVCS との関係よりも使いやすさの観点から言えば、

于 2010-04-01T22:04:48.880 に答える
1

ローカル ヒストリーやローカル ビルドの価値がわからない場合は、いくら質問に答えても気が変わるかどうかはわかりません。

IDE の履歴機能は限定的で扱いにくいものです。それらは完全な機能のようなものではありません。

このようなものがどのように使用されるかの 1 つの良い例は、さまざまな Apache プロジェクトです。git リポジトリを Apache svn リポジトリに同期できます。その後、私はすべて自分のプライベートブランチで1週間働くことができます. レポから変更をダウンマージできます。変更、小売または卸売について報告できます。完了したら、それらを 1 つのコミットとしてパッケージ化できます。

于 2010-04-01T21:51:22.050 に答える
1

ここでは何も売るつもりはありません。

• ローカルでコミットすることの利点または価値は何ですか? 何?本当?最新のすべての IDE で、変更を追跡できますか? 必要に応じて、特定の変更を復元できます。また、IDE レベルで変更/バージョンにラベルを付ける機能もあります!?

唯一の本当の利点は、メインの中央リポジトリへの接続が必要ないことです。Git の利点は、開発者がローカルでコミットし、パッチの優れた組み合わせを準備してから、それらを祝福された中央リポジトリにプルできるという事実だと言う人もいますが、IMO これはかなり面白くありません。開発者は、Subversion リポジトリのプライベート シェルブまたはブランチを使用して自分のタスクに取り組み、それをメインライン (/trunk など) または別のブランチとマージできます。

私にとっての主な欠点は、自分のマシンに Git リポジトリ全体をダウンロードして保存する必要があることです。長い歴史を持つ大規模なプロジェクトでは、それは苦痛になり、スペースを取りすぎます。

一元化されることのもう 1 つの欠点は、Git が技術的に名前の変更やコピー操作を追跡できないことです。ファイルの内容に基づいて、ファイルの名前が変更されたかコピーされたかを推測しようとするだけです。これにより、次のようなおかしなケースが発生します:コピーされたファイルの履歴を保持する svn から git への移行(Guy は、SVN>Git 移行後にファイルの履歴が失われた理由を尋ねています)。

• ハードドライブをクラッシュさせたらどうなりますか? 私のローカルリポジトリはどこに行きましたか? (では、中央レポにチェックインするのと比べて、どのようにクールなのですか?)

Git では、ローカル ストレージ デバイス (HDD、SSD など) がクラッシュし、祝福された Git のレポにプルまたはプッシュされていない変更があった場合、運が悪くなります。時間とコードを失っただけです。これに加えて、ローカル Git リポジトリでハード ドライブがクラッシュすると、しばらくの間開発プロセスが停止する可能性があります。Linus Torvald の SSD が破損し、Linux カーネル開発が停止します

SVN などの集中型ソース管理では、すべての作業がブランチ、プライベートシェルフ、さらにはトランクの中央リポジトリに既にコミットされているため、最後のコミットを失うことしかできませんでした。明らかに、中央リポジトリにディザスター リカバリーとバックアップが実装されていることを確認する必要があります。

• Ok Linus Torvalds は Git に人生を捧げ、それ以外はすべて嫌いです。それはやみくもに賛美を歌うのに十分ですか?Linus は、私の中規模プロジェクトのオフショア開発者とは違う世界に住んでいますか?

過去に BitKeeper を使用した Linux Kernel などのプロジェクトでは、Git が最適なソース管理システムです。しかし、Git はすべての人に適しているわけではありません。

賢明に選択してください!

于 2016-01-02T17:06:12.107 に答える
1

Subversion は将来、オフライン コミットなどを取得する可能性があることに注意してください。もちろん、これらの機能を現在利用可能なものと実際に比較することはできませんが、ここの他の回答で説明されているように、「DVCS を一元的に使用する」ための非常に良い方法かもしれません。

別の最近の投稿では、Subversion は DVCS になろうとしていないと述べています。

これらのことはおそらく、リポジトリがまだ集中化されていることを意味します。つまり、切断された分岐や古いバージョンの差分は実行できませんが、コミットをキューに入れることはできます。

于 2010-04-03T09:30:36.903 に答える
-1

ほとんどの場合、ここでは誰もあなたに何も売りません。git の機能が必要な場合は、git init. それがあなたに合わない場合は、しないでください。

git の機能をまだ知らない場合はgit vs、Google 検索に入力して (末尾のスペースに注意してください)、オートコンプリートの結果を確認してください。

Netbeans 機能が必要になるまでは、IDE よりもメモ帳の方が好みでした。ここも同じケースのようです。

ご存知のように、VCS をまったく使用せずに成功したプロジェクトは数多くあります。

PS。git の販売はライセンス違反です! ;)

于 2010-06-13T17:37:02.470 に答える