ご存知のように、git は最近非常に人気があります。ローカル コンピューターにすべての履歴があり、履歴の取得がネットワークなしで実行できるため、非常に効率的であるためです。おそらくエクストラネット ユーザーにとって、ネットワークの問題はそれほど重要ではありませんが、git には軽量ブランチなど、他の種類の利点もあります (git のブランチと svn のブランチの違いは何なのか、なぜ git のブランチが軽量なのかはまだわかりません)。
また、多くの人がまだ転覆を使用していることも知っていますが、なぜですか? git がそれほど優れている場合、彼らは git に切り替える可能性があります:)
では、転覆の利点を教えてくれる人はいますか?
もう1つの質問:
is there anything which can be done by svn, but cannot be done with git?
記事「Git について嫌いな 10 のこと」と StackOverflow スレッドSVN vs Gitを読むことをお勧めします 。Subversion と Git に関するこのドキュメントも読むことをお勧めします。
他の人はすでにシンプルさ(シンプルさは Apache Subversion のトレードマークです;)ところで) と明確なワークフローを Subversion の主要な利点として挙げていますが、私は他の重要な Apache Subversion の長所をいくつか追加したいと思います:
IDE 統合と GUI の改善。 ほとんどの IDE に組み込みの SVN クライアントが表示されます (またはプラグインとして実装されます)。それらのいくつかは、IDE との非常に快適で直感的なバージョン管理統合を提供します。一方、Git には、よく知られている GitHub を除いて、優れたグラフィカル インターフェイスがありません。IDE 統合もまだ進行中ですが、Git のハックなコマンドラインの性質は実際には GUI に変換されません。分岐やプル/プッシュよりも複雑なことには、コマンドラインを使用する必要があります。
ところで、TortoiseSVN Subversion クライアントは、Windows で利用できる最高のバージョン管理クライアントと見なすことができます。
Subversion は集中化されています。言い換えれば、分散システムはいわゆる「次世代 VCS」ではなく( Eric Sink さん、こんにちは!)、ただの分散システムです。分散は、Linux カーネル (Git は Linux カーネル用に開発されたものですよね?) などのオープンソース プロジェクトに最適なもう 1 つのアプローチですが、独自の欠点もあります。
完全な改訂履歴。SVN は、ディレクトリ、名前の変更、およびファイル メタデータのバージョン管理を維持します。Subversion は不変の歴史を持つタイム マシンのように機能します。2009 年 1 月 3 日などの日付がどのように表示されたかを確認するために、マシンをいつでも使用して過去にさかのぼることができます。
部分的なチェックアウト。Subversion では、完全なリポジトリのクローンを取得する必要はありません。プロジェクトの特定のブランチまたはトランクをチェックアウトできます。さらに、リポジトリの任意のサブツリーを取得できます。タスクの作業を開始するために必要なトラフィックを大幅に最小限に抑えます。すでに作業コピーがある場合、別のブランチまたはシェルブへの切り替えはすぐにできます (リモート リポジトリに接続できる場合はもちろん)。
ロッキングサポート。Subversion は、lock-modify-unlock バージョン管理モデルをサポートしています。Git にはありません。これは、マージできないファイルがある場合に非常に役立ちます。こんにちは、ゲーム開発者です！:)
シンプルさ。
「リモートとは何ですか?」、「なぜメッセージを修正するのですか?」、「このリベースとは何ですか?」などの質問。Git が提供するすべての機能を理解するために必要であり、Git がなぜそれほど優れているかを本当に理解するには、それらを理解する必要があります。
しかし、Git を使い始めるデザイナーや技術者にとって、これは単なる頭痛の種です。Subversion はよく知られており、その集中化された方法により、これらすべての人々にとってより理解しやすくなっています。
Subversion を使用すると、作業と作成をはるかに高速に開始できます (既に環境がセットアップされている場合 ;))。
Git は個人の力を持つことについてですが、Svn は企業の力について (壮大な主張として) についてです。
Git は、危害から保護する必要があるマスター ドキュメントがなくなったことを認識しています。むしろ、sha1 によって検証されない限り、管理がより困難なコピーが多数存在するようになりました。
Svn は人々が愚かであることを知っています (しかし、あなたや私はそうではありません;-) そして、誰が名前を変更し、何が重要であるかを知っており、その内容は後で承認できると考えています。
Git を使用すると、ハサミで走ったり、チェーンソーをジャグリングしたり、製品を作成したりできます。Svn は、防護服、作業指示、およびセキュリティの種類を提供します。
床に釘付けにしたい足を選択することです;-)
Git ブランチは、単にポインターである限り「軽量」です。git は、特定のコミットで「master」、「development」、「trunk」、または「myfeature」を指すだけです。ブランチで新たにコミットすると、ポインターが進みます。この主題に関する優れたリソースであるgit-scm docsのこの図を検討してください。
この図の 'master' ブランチは commit を指していf30abます。「testing」ブランチは commit を指していc2b9eます。HEADこの図の は特別なポインタです。ほとんどの場合、作業ディレクトリの現在チェックアウトされた状態を示すために、別のブランチ (git 用語では「シンボリック参照」) を指しています。たとえば、を発行すると、git checkout f30abリポジトリが「切り離された HEAD」状態になります。つまり、ポインターをシンボリック参照「テスト」からコミットに移動しますf30ab。
例を挙げてみましょう。ローカルで自分自身をセットアップできるはずです。
git init /tmp/test && cd /tmp/test ;# make a repo and cd to it
echo A > A ;# add a file
git add A && git commit -m "first commit" ;# make the first commit
echo B > B ;# add another file
git add B && git commit -m "second commit" ;# commit that one too
git checkout -b development ;# now let's checkout development
echo C > C ;# commit one more file
git add C && git commit -m "third commit" ;# and commit that final one
あなたは今、以下のようなものを手に入れました。私は omnigraffle を持っていないので、有向グラフに固執しています:
* 93e71ee - (HEAD, development) third commit
/
* 6378754 - (master) second commit
* d2b4ba9 - first commit
括弧から推測できるように、'master' は commit を指し6378754、'development' は commit93e71eeをHEAD指し、'development' を指します。私の言葉を鵜呑みにしないでください。自分でポインターを調べます。
$ cat .git/refs/heads/master ;# cat the 'master' pointer
5a744a27e01ae9cddad02531c1005df8244d188b
$ cat .git/refs/heads/development ;# now cat the 'development' one
93e71ee0a538b0e8ac548e3936f696fa4936f8dc
$ cat .git/HEAD ;# note that 'HEAD' points at 'development'
ref: refs/heads/development
$ git symbolic-ref HEAD ;# as we can also show with 'symbolic-ref'
refs/heads/development
ブランチが単なるポインタである場合、ブランチ間の切り替えは簡単です。1 つの特別なケースはHEAD. マスターをチェックアウトするとどうなるかを考えてみましょう:
$ git checkout master ;# checkout master...
$ cat .git/HEAD ;# where are we now?
ref: refs/heads/master
コミットをチェックアウトするのはどうですか？
$ git checkout d2b4ba9 ;# this will throw some advice
Note: checking out 'd2b4ba9'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
$ cat .git/HEAD ;# 'HEAD' points at a commit
d2b4ba97698d7f528f9ba1e08d978a70651b3b1d
$ git symbolic-ref HEAD ;# and thus isn't a symbolic reference
fatal: ref HEAD is not a symbolic ref
そのアドバイスはどういう意味ですか？「切り離されたHEAD」状態のリポジトリに対してコミットすると、どのブランチからも到達できないコミットが生成されるということです。HEAD( などのチェックアウト操作から) 変更するgit checkout masterと、それらのコミットは失われます。これは、グラフで見ると簡単です。
echo D > D ;# add another file
git add D && git commit -m "fourth commit" ;# and commit it
グラフを見てみましょう。git コマンドは、以下に表示されるものを生成しないことに注意してください。この例のために、既存の出力を変更しました。
* 93e71ee - (development) third commit
/
* 6378754 - (master) second commit
/
* / 72c1f03 - (HEAD) fourth commit
|/
* d2b4ba9 - first commit
HEADまだ離れています。を指してい72c1f03ます。'master' と 'development' は、予想される場所ですが72c1f03、どのブランチからも到達できません。それは問題だ。維持したい場合は72c1f03、ブランチを作成する必要があります。
$ git checkout -b experimental ;# checkout 'experimental' based on '72c1f03'
$ cat .git/HEAD ;# HEAD is once again pointed at a branch
ref: refs/heads/experimental
$ git symbolic-ref HEAD ;# and is a symbolic ref
refs/heads/experimental
そしてグラフ：
* 93e71ee - (development) third commit
/
* 6378754 - (master) second commit
/
* / 72c1f03 - (HEAD, experimental) fourth commit
|/
* d2b4ba9 - first commit
Git は分岐を容易にします。ポインターに関する情報のプッシュとプルは、ファイル セット全体のプッシュとプルよりもはるかに高速です。ブランチのカットには数ミリ秒かかります。とても簡単で、ほとんど間違っているように感じます。その結果、git はより多くの分散型ワークフロー オプションを許可しますが、集中型のものも確実に処理できます。
SVN から git への切り替えは、社内で多くの変更 (トレーニング、サーバー、問題追跡などの他のツールとの通信...、セキュリティ) を必要とするため、骨の折れる作業です (私の会社では 6 か月間使用しています)。 ）。
私が見つけることができる唯一の利点は、その単純さです (git よりも多くのことを実行できないため)。ワークフローは理解しやすく、適用しやすいため、すべての同僚が git の複雑さを処理できる/処理したくない、または処理できないと心配している場合その機能が必要な場合は、svn を使用してください。
このSOスレッドを見て、自分自身を納得させてください:)。