GITにジャンプする前にSVNを理解する必要がありますか?[閉まっている]


31

私は、自分自身を含めて誰もソース管理を使用したことがない部署で働いています。

私はコンセプトをプッシュしようとしています。SVNの調査に少し時間を費やしました。いくつかの基本を学びました。コマンドラインおよびTortoiseから作成/更新/チェックアウト/コミットできます。私はタグ付けと分岐の方法を学び始めていますが、それでも分岐とトランクなどの間の競合については多くの混乱を覚えています。書籍/チュートリアルと試行錯誤からのすべて。

私がオンラインで読んだgitことから、知るほうが良いように思えますが、より複雑です。自分を圧倒したくありません。gitに移動する前にsvnをマスターし続ける必要がありますか、それともgitにジャンプする方が賢明でしょうか?

両方のアプローチに賛否両論はありますか?


stackoverflow.com/questions/161541/svn-vs-git/2549128#2549128を参照してください。どちらも根本的に異なり、より一般的には、CVCSとDVCSは(stackoverflow.com/questions/2704996/…およびstackoverflow.com/質問/ 2563836 /…
VonC

1
gitref.orgは、Gitを学習するための優れたソースです。
ジェレミーハイラー

4
いいえ、それはあなたの心を曇らせます、そして、あなたは「転覆再教育」を必要とします。git / mercurialも優れた技術です。Subversionで同僚をトレーニングすると、後で最適なツールに切り替えることが難しくなります。
Keyo

Gitは試してみてください簡単に、うまく設計された初期もちろんいいです
ベンBrocka

回答:


58

いや

GitはSVNとは根本的に異なるため、役に立ちません。どちらかといえば、「更新」コマンドと「コミット」コマンドを探して、なぜすべてが違うのか疑問に思うでしょう。

Gitをボトムアップから始めて、そこから始めます。


標準の集中更新/コミットパターンバージョン管理システムとGitを対比することは、バスと大量輸送を比較するようなものです。バスは、まったく同じルートを使用して、ポイントAからポイントBに移動します。大量輸送では、好きなルートを使用してポイントAからポイントBに移動できます。

分散自体には、注意すべき欠点があります。全員を同じページに留めるには、より多くの作業が必要です。ただし、柔軟性が大幅に向上します。


リビジョンハッシュと数字

誰かがGitがSHA1ハッシュを使用しているのに、Hgは数字を使用していると言いました。

最初に、毎日のコミット/プルでハッシュを直接処理する必要はほとんどありません。差分またはよりトリッキーなリベースアイテムを実行している場合は、ログをプルアップしてハッシュをプルする必要があります。

Gitを使用すると、誰もが同じハッシュを使用できます。異なるリポジトリには異なるコミット番号がなく、全員が同じページにいます。Hgではこれはそれほどではありません。実際には、コミットハッシュをプルアップして操作する必要がある場合(コードのタイムラインを比較またはトラバースするために)、数字の代わりにハッシュを使用すると、他の人と簡単に同期できます。


3
たぶんそれは米国のものですが、「大量輸送」は「公共交通機関」、すなわちバス、電車などと同じではありませんか?
ディーンハーディング

@ディーン:はい、彼らは同じです。「公共交通機関」よりも一般的だと感じたため、大量輸送機関を使用しました。
ジョシュK

私は「MassTransit」(としてのコメントを読むまで、私の持っていたビットが混乱しmasstransit-project.com)...また、バスで
FinnNk

3
私は大きなNOを考えていましたがそれが現れました。+1
ZJR

22

いいえ、気にしないでください。

真剣に、DVCSから始めます。SVNが普及しているという事実は、SVNを標準にはしていません。リーナス・トーバルズは、それがあなたの脳を腐らせるかもしれないとあなたに言うでしょう。

Subversion Re-educationというJoel Spolskyによるこの素晴らしい記事/紹介を読んでください。

また、この他の質問を読むことに興味があるかもしれません:私はSubversionオタクです。なぜMercurialやGit、または他のDVCSを検討する必要があるのですか?

DVCSの選択

個人的には、mercurialとgitの両方を使用していますが、両方を知ることは重要だと思います。これに関する推奨読書は、Git対Mercurialです。リラックスしてください(git-addremoveの例を参照)。私はそれを要約すると思うその記事からの2つの引用。

gitについて:

Gitの設計哲学は間違いなくUnixのそれです。Subversion、CVS、またはMercurialとは異なり、gitは1つのモノリシックバイナリではなく、git-pull、git-merge、 git-apply、git-hash-object、git-merge-fileなどの低レベルの「配管」コマンドに対するgit-checkout。したがって、MacGyverのように、Gitで必要なことはほとんど何でもできます。これには、すごいWikiエンジン、問題追跡システム、ファイルシステム、システム管理ツールなど、ヒューズの修理以外のすべてが含まれます。

水銀について:

システムをクリーンに保ちたい開発者は、hgがgitを構成する144とは対照的に1つのバイナリをインストールするという事実をたぶん評価するでしょう。シンプルさhgは、その特定の機能を省略して提供します。

多くのプロジェクトはgithubで見つけることができ、gitはより強力ですが、新参者、特にWindowsユーザーにとってはやや怖いかもしれません。bitbucketもあります(githubのMercurialに相当)。

私の推奨事項:Mercurialから始めて、使い始めたらすぐにgitを入手してください。それはツールについてではなく、あなたが働く人々についてです

Subversionの実際の実用的な使用方法は、他の人と作業するためではなく、おそらく実稼働アプリケーション用のアップデータを実装するためです。その理由は次のとおりです。

  • 現在、svnはほとんどのホスティングプロバイダーにほとんどインストールされています
  • サブプロジェクトのサポートが良好です(ただし、現在gitおよびhgでアドレス指定可能)。svn upプロジェクトとその依存関係が更新されます。

この他のスレッドでThorbjørnを引用:

DVCSesはSubversionへ、Bittorrentはftpへ

編集:Gitの前に知っておくべきVCSがある場合、それはMercurialである可能性があります(より使いやすいCLIインターフェースであり、分散概念を紹介するのに適しています)。CLIもある程度類似しているため、このアドバイスはSubversionからのユーザーに特に当てはまります。分散バージョン管理は、集中管理されたバージョン管理よりも簡単に学習できます。これは、クライアントとサーバーの部分を別々に考えるのではなく、リポジトリインスタンスだけを心配するためです


1
有用なリンクの場合は+1。Subversionは十分に簡単であり、十分に文書化されているので、メンタルモデルにソース管理のアイデアがあれば、必要なものとして取り上げることができます。
ゲイリーロウ

2
前にSVNを使用すると、心を汚す可能性があります。


1
hgを使用する主な理由は、より優れたWindowsサポート
jk

1
WindowsのGitサーポートを見ると、多くのGitユーザーウィンドウを使用する人を憎んでいることがわかりました。
イアン

4

使用するものを学習する必要があります。Mercurialが人気を博したように、Gitも人気があります。Git / Mercurialは両方とも分散ソース管理システムです。

チームに新しい概念を導入する際に最も重要なこと(バージョン管理が多くのチームにとって新しいトピックと見なされることは残念ですが)、それはあなたの目標と評価基準を概説するのに役立ちます。それについて超形式的である必要はありませんが、次の質問を自問してください。

  • で、バージョン管理の目的は何ですか、私たちのチームは。はい、すべてのバージョン管理システムは価値があり、履歴に戻って特定のファイルの変更点を確認できます。ただし、新しいリリースのベースラインとして使用する予定ですか?(頭をうなずく、これが欲しい)。これは、達成したいことに対する2〜3行のビジョンステートメントです。
  • あなたのチームは、後で慎重に物事をマージするためだけに独自のローカル作業環境を持つことに慣れていますか?その場合、DVCSルートが最も意味があります。
  • 逆に、チームは1つの共有ドライブから作業することに慣れていて、すべてが常に統合されていますか?もしそうなら、より伝統的なVCS​​が最も理にかなっているかもしれません。

選択肢を評価するときは、すべてのVCSが行う必要がある重要なことを考慮する必要があります。

  • ベースラインコード(タグ付きブランチ、ラベルなど)。基本的に、プロジェクトのリリースで使用される正確なソースコードをどのように取得しますか。
  • 中央サーバーへのローカル変更を取得します。DVCSを使用する場合でも、標準VCSを使用する場合でも、コードの信頼できるコピーが必要です。各ツールはこのプロセスを異なる方法で処理します。
  • 中央サーバーでローカルコピーの変更を取得します。
  • 実験的な変更に対処する方法。VCSを使用すると、メインプロジェクトのソースコードを壊すことなく、提案された変更をより大胆に行うことができます。DVCSと標準VCSシステムのアプローチはまったく異なります。そのうちの1つがチームに最適です。
  • サーバーをどのようにセットアップして構成しますか?
  • 認証が必要ですか?もしそうなら、実際に変更を行うことを許可されている人だけが実際にできることをどのように確認しますか?

最後に、迅速な評価を行って、標準のVCSまたはDVCSシステムがチームに最適かどうかを判断します。痛みを最小限に抑えるツールを選択する必要があります。そうしないと、採用されない可能性があります。その後、ニーズに最適な代替案を評価します。

最後に、使用するものを学習します。


3

多くの人がgitがsvnよりも複雑だと思うのは、それが違うからです。Subversion(またはcvsなど)をしばらく使用した後、モードをDVCSモデルに精神的に切り替えるのは難しい場合があります。それに基づいて、gitのようなDVCSの調査と並行して、Subversionのような従来のVCSを調査することは、あなたにとって重要なことかもしれません。

gitは私の好みのVCSですが、おそらく同様に転覆を学ぶのが最善だと思います。1つは、1日のやり取りが必要なSubversionリポジトリとcvsリポジトリがまだたくさんあり、DVCSが従来のVCSと比較して正確な長所と短所をよりよく理解できることです。


手続き型言語で作業していない方が、Schemeのような言語を習得する方が簡単であるという証拠を見てきました。これも同様に機能します。
デビッドソーンリー

したがってgit-svn clone、リポジトリと対話するために使用します。
Keyo

3

svnを学習してからgitを学習すると逆効果になる

いくつかの理由があります。

  • svnとは根本的に異なるGits。Gitは分散しており、svnはクライアント/サーバーです。
  • 同じ単語には異なる意味が付いています。たとえば、「git checkout ...」は「svn checkout ...」とは異なる意味を持ちます
  • 分岐は異なります。Gitには、svnがサポートしていない安価なローカルブランチである「トピック」ブランチという概念があります。
  • Gitにはインデックスと呼ばれる余分な場所があり、作業ツリーとリポジトリの間にあります。SVNにはインデックスがありません。gitを使用すると、作業ツリーからリポジトリのインデックスに変更が移動します。

私のアドバイスはgitを学ぶことです。


2

GITとSVNで広く同じものとそうでないものがあります。

作成/更新/チェックアウト/コミット

ほぼ同じですが、簡単に手に入れることができます。

タグを付けてブランチする方法ですが、ブランチとトランクなどの競合についてはまだ混乱しています

2つの間で異なります。

今すぐ変更すべきだと言ってはいけません(それがあなたの電話だと思います)。確かにGitを試してみたい場合は、今すぐ切り替えて、Gitとは異なるSVNで何かを学んでおくことをお勧めします。


また、Subversionのbashersに耳を傾けないでください。どちらかを使用することは、これを導入するためにあなたにあまり良いものを使用しないよりもはるかに優れています。VCを2つの小さな会社に紹介しましたが、大変ですが価値があります。
ジェームズ

+1すばらしい情報ありがとう。私がジャンプしようとしていたように、今は良い時間になるでしょう。
JDアイザックス

そして転覆の場所はどこですか?

2

ワオ; 12の答えと誰もがまだ質問を懇願しています...

いいえ、SubversionはGitの前提条件ではありません。

SubversionとGitの間に明確なマッピングはありません。両方を学習する場合、異なるアクションに対して同じ用語を使用するという事実に苦しむ必要があります。(および同じアクションに対する異なる用語。)

  • svn commitは以外のものですgit commit
  • svnとgitのブランチは非常に異なります
  • svnリポジトリはgitリモートのようなものです(実際はそうではありません)
  • gitリポジトリはsvnの作業コピーに似ています(しかし実際はそうではありません)

これらは、共通言語で分割された2つのツールです。

あなたの質問、および他のほとんどの答えは、gitが何らかのsvn ++であると仮定しています。「より良いsvn」。そうではありません。この2つは、車やオートバイのように、同じ空間で機能するさまざまなツールです。

1つを選んで習得し、チームで使用を開始することをお勧めします。バージョン管理を習得するのは、それを使用したことがない人にとっては難しいでしょう。VCSはインフラストラクチャの重要な部分になります。VCSを信頼するためには、新しい作業習慣を構築する必要があります。それには時間がかかります。

(いずれにしても、システム管理者がマスターリポジトリをバックアップしていることを確認してください。ソース管理を失うことは壊滅的です。)


1

おそらくそうではありません-サーバーベースと分散には十分な違いがあるので、おそらくあなたはさらに混乱するでしょう。

最初からお好みのDVCSを使用してグッドプラクティスに従うように設定します。最初から始めれば、おそらくずっと幸せになるでしょう。

(圧倒されたくない場合は)Mercurialをご覧ください。


2
あなたが少なくとも投票した場合は、説明の礼儀を教えてください。ありがとう。2つの可能性:1)答えを修正するか、2)削除するかもしれません...しかし、これが欠陥だと思う理由を実際に知っている場合にのみ
-Murph

1

Gitには、中央リポジトリへのコミットとプッシュの区別があるため、GitはSubversionよりわずかに複雑です。

Subversionであなたの心を破壊する機会がある間、Gitを学ぶ価値があります。


1

Gitを理解するにはSubversionを理解する必要はないと思います。

少なくとも私にとって、SubversionのGitとMercurialとの最大の違いは、作業するローカルリポジトリがあること、コードが機能するまでそこにチェックインおよびチェックアウトすること、中央リポジトリからチェックアウトすること、競合を修正すること、チェックインしてサーバーにプッシュします。


1

Unix環境(Linux、MacOS X)のgitが本当に好きです。Windowsでは、少しハックします。方程式にWindowsがある場合、Mercurialを検討します。

履歴クラスが気に入ったので、SCCS、RCS、CVS、Subversionを試してから、GitやMercurialなどの便利なものを使用してください。

GitとMercurialは等能力であり、Gitの大きなボーナスはgithubです。ただし、バージョン管理をアウトソースしたくない場合は、GitHubはもう関係ありません。


1

バージョン管理システムは、プログラミング言語と共通点を共有します。最初に学習するのに時間がかかるからです。その後、新しいシステムを選択するのは、新しいシステムによってコアコンセプトがどのように表現されるかを学ぶだけです。

今すぐGitを学習し、必要に応じて後でSuvbersionの学習に時間をかけることができます。


0

いや。Gitをダウンロードし、GitHubアカウントを作成し、レポジトリをフォークするなど、数日間台無しにします。Gitを使用するのは簡単です。5つまたは6つのbashコマンドを学ぶと、すべての重要なタスクを実行できます。私は一般的にGUIの「ばかさ」を好んでいますが、Git Bashはそれと同じくらい簡単です。また、そのルートを好む場合、Git Guiはかなりまともです。SVNを学習することで得られるメリットはあまり見当たりません。しばらく前に、新しいオープンソースプロジェクト用にいくつかの異なるバージョン管理システムを評価していました。SVN、Bazaar、Git、およびその他のカップルを試して、それぞれの基本を学びました。YMMVですが、Gitははるかに簡単でした。SVNの学習にも何も問題はありませんが、Gitを学習するのに役立ちません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.