为什么别人总说 linus 反感SVN，是因为他必须连网才能使用，所以不用他，说得好像GIT不联网就能使用一样，不联网他咋提远程服务器啊？
他の人のコードとマージするには、最終的にはインターネットに接続する必要があるのは事実です。
しかし、この文が意味するのは、Git にはローカル ウェアハウスがあるため、バージョン管理のためにインターネットに常に 接続する必要がないということです。ブランチの作成、送信、コードのロールバックなど、インターネット接続を必要とせずに、バージョン管理に関連する多くの作業をローカルで実行できます。 Git不需要总是联网就能进行版本管理，因为它有本地仓库。你可以无需联网，在本地就能进行很多版本管理相关的工作，例如创建分支、提交、回滚代码等
Git
常に
总是
对始终坐在一间办公室，使用局域网工作的常规的小规模团队，可能无法充分体会到Git的好处，换句话说，对于一般的情况，SVN已经足够胜任了。
SVN
然而对项目成员可能分布在任何地方的“非常规”团队来说，Git可能要更优秀一些。
本来想在评论里直接回复你的，但内容有点多，所以还是加到这里吧。
从你的疑惑中能看出来，你可能还不太理解版本管理的本质。版本管理中的版本并不单单指软件最终的发行版，0.8、1.0、2.0这些只不过是面向最终用户的版本而已。版本管理中的版本是泛指那些在开发过程中程序的中间状态。这些版本有些需要合并到公共版本里去，有些可能最终就丢弃了，甚至从此就演化出了另一个项目也不一定。可以说，你每按下一次Ctrl+S
版本管理
版本
Ctrl+S
です。 SVN
バージョン管理
version
しかし、Git では、最初にローカルで送信されるため、送信動作にバッファ時間が与えられ、他の人に影響を与えることなく時間内に元に戻すことができます (遅すぎるとわかった場合は、何もすることができません)。
「ローカル」ロールバック機能もあります。関数は比較的複雑で、開発には数日かかりますが、他の人に影響を与えたくないので、開発前にサーバーに送信したくありません。コンパイルまたは実行エラーが原因です。そのため、すべてをローカルで変更してから送信したかったのですが、この方法では、これらのプログラムはロールバックしたり、以前のコードと比較したりすることが保証されていないため、それが困難です。
一部のツールにはローカル履歴機能もありますが、それは簡単ではありません。ローカル履歴を毎回バージョンと比較することはできません。言い換えれば、地域の歴史は、あなたが望むように記録を保存しないのです。緊急に必要な履歴記録が保存されていない可能性が非常に高く、それを眺めてため息をつくことしかできません (この問題は実際にはそれほど珍しいことではありません) Ctrl+S
質問者は、一人でオフラインで使用できる git の利点に焦点を当てすぎています。Git は分散構造であるため、そのデータの整合性は svn よりも優れているはずです。ウェアハウス ファイルの破損 (これは簡単に起こります。停電など)、svndump を使用してエクスポートされたすべての履歴コミットにも不可解な問題が発生します。
さらに、対象者が触れる可能性のあるプロジェクトの規模はまだ比較的小さく、基本的には依然として svn のような git を使用しているため、競合とマージの問題に焦点を当てています。私が言いたいのは、競合はもちろん解決する必要がありますが、バージョン管理の基本的な目的は、コードをマージして競合を解決することだけではなく、最も重要なことは、他の人やリリースに影響を与えずに全員が作業できるようにすることかもしれないということです
当社の git の使用は、git flow の慣例に従っています。Master はトランク リリース (Web プロジェクトなので、常に反復される安定したバージョン) に使用され、Develop は新しい要件の開発を開始する全員のテストに使用されます。開発ブランチからの機能をブランチし、作業が完了したら開発にマージし、すべてがOKであればリリースをマスターにマージし、次のリリースを待ちます。これを言うのは、自分自身の機能ブランチで言及することです。開発ブランチで作業するとき、実際には、開発ブランチで何が起こっているかをあまり気にする必要はありません (中央サーバーと対話する必要はありません)。バージョン管理の必要性は依然として存在しており、機能を何度も完成させる必要がありますが、それを送信することによってのみ解決できます 緊急に修正する必要があるパッチの場合は、マスターからホットフィックスブランチを作成し、それをマージします。修正後はマスター（そして開発）に戻ります
。
は集中型と分散型の違いです。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
他の人のコードとマージするには、最終的にはインターネットに接続する必要があるのは事実です。
しかし、この文が意味するのは、
Gitにはローカル ウェアハウスがあるため、バージョン管理のためにインターネットに常に接続する必要がないということです。ブランチの作成、送信、コードのロールバックなど、インターネット接続を必要とせずに、バージョン管理に関連する多くの作業をローカルで実行できます。Git不需要总是联网就能进行版本管理，因为它有本地仓库。你可以无需联网，在本地就能进行很多版本管理相关的工作，例如创建分支、提交、回滚代码等对始终坐在一间办公室，使用局域网工作的常规的小规模团队，可能无法充分体会到
Git的好处，换句话说，对于一般的情况，SVN已经足够胜任了。然而对项目成员可能分布在任何地方的“非常规”团队来说，
Git可能要更优秀一些。本来想在评论里直接回复你的，但内容有点多，所以还是加到这里吧。
从你的疑惑中能看出来，你可能还不太理解
常にオフィスに座って LAN を使用して作業する従来の小規模チームは、版本管理的本质。版本管理中的版本并不单单指软件最终的发行版，0.8、1.0、2.0这些只不过是面向最终用户的版本而已。版本管理中的版本是泛指那些在开发过程中程序的中间状态。这些版本有些需要合并到公共版本里去，有些可能最终就丢弃了，甚至从此就演化出了另一个项目也不一定。可以说，你每按下一次Ctrl+SGitの利点を十分に理解できない可能性があります。つまり、一般的な状況では、です。 SVNで十分です。
ただし、プロジェクト メンバーがどこにでも分散している「型破りな」チームの場合は、Gitの方が適している可能性があります。
本当はコメントで直接返信したかったのですが、内容が多かったのでこちらに追記させていただきます。
あなたの疑問から、バージョン管理の本質を完全に理解していない可能性があることがわかります。バージョン管理におけるバージョンは、ソフトウェアの最終リリース バージョンだけを指すわけではありません。0.8、1.0、および 2.0 は、エンド ユーザー向けの単なるバージョンです。バージョン管理のversionは、通常、開発プロセス中のプログラムの中間ステータスを指します。これらのバージョンの一部は公開バージョンにマージする必要があり、一部は最終的に破棄されたり、その後別のプロジェクトに発展したりする可能性があります。Ctrl+Sを押すたびにバージョンが作成されると言えます。
バージョン管理の本質をよりよく説明するために、日常生活でよく遭遇する例をいくつか挙げてみましょう。
シナリオ 1
現在開発中のこの関数についてアイデアはありますが、それが実現可能かどうかはわかりません。そのため、ワークスペース (.多くの場合、SVN のワークスペースはメイン バージョンに直接対応します)。これにより既存のコードが汚染されるため、後でこの方法が不可能であることが判明した場合は、関連するコードをすべて削除する必要がありますが、何を削除する必要があるのか覚えていない可能性があります。その時。 #🎜🎜# #🎜🎜# SVN のような集中バージョン管理ツール (非常に多くの機能や機能がより便利です)、つまりブランチを使用して実装することもできますが、この方法でもサーバーと頻繁にやり取りして作成する必要があります。ブランチ、ブランチの削除、ブランチのマージ、ブランチへのコードのコミットなど。しかし実際には、これらすべてをローカルで行うことができます (これもローカル エリア ネットワークでは大きな問題ではないかもしれません)。ローカル ウェアハウスにブランチを作成し、コードを作成してテストし、機能する場合はそれをマージします。動作しない場合は、動作するかどうかは関係ありません。 #🎜🎜# #🎜🎜#シナリオ2#🎜🎜# #🎜🎜#ある投稿のプログラムの1つが間違っていることに気づきました（例えば、ある関数が半分しか変更されておらず、コンパイルさえ失敗したなど）このときは、素早くロールすることしかできませんでした。しかし、もう手遅れかもしれません。他の誰かがあなたのコードをチェックしたかもしれないので、問題を説明するグループメールを送信する必要があります（または、全員が集まっている場合は怒鳴りつけるだけです）。 #🎜🎜#しかし、Git では、最初にローカルで送信されるため、送信動作にバッファ時間が与えられ、他の人に影響を与えることなく時間内に元に戻すことができます (遅すぎるとわかった場合は、何もすることができません)。
シナリオ 3
「ローカル」ロールバック機能もあります。関数は比較的複雑で、開発には数日かかりますが、他の人に影響を与えたくないので、開発前にサーバーに送信したくありません。コンパイルまたは実行エラーが原因です。そのため、すべてをローカルで変更してから送信したかったのですが、この方法では、これらのプログラムはロールバックしたり、以前のコードと比較したりすることが保証されていないため、それが困難です。
一部のツールにはローカル履歴機能もありますが、それは簡単ではありません。ローカル履歴を毎回バージョンと比較することはできません。言い換えれば、地域の歴史は、あなたが望むように記録を保存しないのです。緊急に必要な履歴記録が保存されていない可能性が非常に高く、それを眺めてため息をつくことしかできません (この問題は実際にはそれほど珍しいことではありません)
まとめCtrl+S
ここまで述べてきましたが、これらは集中型と分散型の間のほんの一部の例にすぎません。実際、この問題はオブジェクト指向とプロセス指向と同様に、絶対的な善悪はありません。複雑なプログラムにはオブジェクト指向を使用する方が良いかもしれませんが、プロセス指向にもメリットがないわけではありません。ツールの選択はチームと個人の決定によって異なります質問者は、一人でオフラインで使用できる git の利点に焦点を当てすぎています。Git は分散構造であるため、そのデータの整合性は svn よりも優れているはずです。ウェアハウス ファイルの破損 (これは簡単に起こります。停電など)、svndump を使用してエクスポートされたすべての履歴コミットにも不可解な問題が発生します。
さらに、対象者が触れる可能性のあるプロジェクトの規模はまだ比較的小さく、基本的には依然として svn のような git を使用しているため、競合とマージの問題に焦点を当てています。私が言いたいのは、競合はもちろん解決する必要がありますが、バージョン管理の基本的な目的は、コードをマージして競合を解決することだけではなく、最も重要なことは、他の人やリリースに影響を与えずに全員が作業できるようにすることかもしれないということです
。当社の git の使用は、git flow の慣例に従っています。Master はトランク リリース (Web プロジェクトなので、常に反復される安定したバージョン) に使用され、Develop は新しい要件の開発を開始する全員のテストに使用されます。開発ブランチからの機能をブランチし、作業が完了したら開発にマージし、すべてがOKであればリリースをマスターにマージし、次のリリースを待ちます。これを言うのは、自分自身の機能ブランチで言及することです。開発ブランチで作業するとき、実際には、開発ブランチで何が起こっているかをあまり気にする必要はありません (中央サーバーと対話する必要はありません)。バージョン管理の必要性は依然として存在しており、機能を何度も完成させる必要がありますが、それを送信することによってのみ解決できます
主にこれらの手段により解決されます緊急に修正する必要があるパッチの場合は、マスターからホットフィックスブランチを作成し、それをマージします。修正後はマスター（そして開発）に戻ります
- 新機能の開発は、他の新機能の開発には影響しません (各機能は独立したブランチです)
- 新しいバージョン (開発中) のアップグレードと古いバージョン (マスター) のバグ修正は、誰かが新しいバージョンを開発するまで待つ必要はなく、古いバージョンのマスターのバグが相互に競合したり影響したりすることはありません。新しいバージョンは開発されてからのみリリースできます
SVN にはこれが可能ですが、そのブランチ機能は基本的にウェアハウス内の別のディレクトリーであり、マージするかどうかは実際には属性によって保存されるため、決して使いやすいものではありません。
追加:
http://git-scm.com/book/zh/v1/%E5%88%86%E5%B8%83%E5%BC%8F-Git-%E4%B8%BA%E9 をチェックしてください。 % A1%B9%E7%9B%AE%E4%BD%9C%E8%B4%A1%E7%8C%AE では、多くの Git ベスト プラクティスを紹介しましたは集中型と分散型の違いです。