私はしばらくの間Subversionを使用してきましたが、最近はGITが大多数の好みのように思われるため、学習してGITに切り替えることを検討しています。
それにもかかわらず、GIT（およびその複雑さの原因）の最大の利点の1つは、分散化できることです。各ユーザーは独自のリポジトリを持ち、必要に応じてリポジトリをマージします。私はこの機能に興味がありません。実際には、私が単独で作業するプロジェクトと、複数の人が常に最新のソースを保存することが期待されるプロジェクトの両方で、すべてを単一のサーバーに集中させたいと考えています。同じサーバーで、ブランチ/フォークがないか、最小限に抑えられています。
これを考慮すると、現在ほとんどの開発はVisual Studioを備えたWindowsで行われており、Linuxからいくつかの単純なsvnコマンドを使用してアクセスする必要がありますが、GITはまだ良いオプションですか？切り替える価値はありますか？GITが提供する他のどのような機能が私たちに利益をもたらしますか？
これをまっすぐにしましょう。
では、なぜGitに切り替えるのですか？
GitにはSubversionよりも「優れている」というおしゃべりがたくさんあることは知っていますが、そのほとんどはバージョン管理を本当に知らない人たちです。彼らは、多くのオープンソースプロジェクトがGitを使用していることを確認し、LinuxがGitを使用している場合は、それがより優れているに違いないと考えています。
私はGitとSubversionの両方を使用していますが、それぞれに長所と短所があります。
Gitの問題は、顧客が成果物を課し、リリース期限を設定したときに現れ始めます。母鶏のように開発者がいない限り、Gitは継続的インテグレーション環境ではうまく機能しません。何が起こるかというと、リリースサイクルが終了するまで、変更は中央リポジトリに配信されません。次に、リリースの最後の数日間、非互換性、競合、およびその他の問題を処理しようとして立ち往生しています。
Subversionのような一元化されたリポジトリでは、開発者は協力することを余儀なくされています。彼らは彼らのコードに、より小さく、より漸進的な変更を加えます。優れた継続的インテグレーション環境により、QAチームは中間リリースを引き出し、最終リリースを待たずにテストを行うことができます。
ボーナスとして、SubversionはAnkhSVNを介してVisualStudioとの優れた統合を実現しています。ついにVisualStudio用のGitソースコードプロバイダーができましたが、それはTortioseGitとBASHシェルに依存しています。一方、AnkhSVNは完全にカプセル化されたソースコードプロバイダーであり、そのインターフェイスはVisualStudioまたはTeamFoundationを使用しているかのように似ているため、VisualStudio開発者はそれに精通しています。
したがって、すべての開発者がGitを必要としている場合、またはGitの分散機能を使用する予定がない限り、切り替えるためだけに切り替える理由は実際にはありません。
SVNからGitに切り替えたいと思う主な理由は2つあります。
しかし、あなたが言ったように、Gitの警告はそれが集中化できないことです：わかりました、あなたは中央サーバーを持つことができます、しかしあなたはローカルリポジトリも持つ必要があるので、開発者は以下をする必要があります：
2つのステップ。通常は問題にはなりませんが、SVNを継続する主な理由となる場合があります。
そうは言っても、Gitは優れたオプションですが、基本的にVisual Studioを使用していることを考えると、www.plasticscm.comをご覧ください（免責事項：私はこの会社で働いています）。最近、gitサーバーに直接プッシュおよびプルできる機能をリリースしました...混合アプローチが必要な場合に備えて：http：//codicesoftware.blogspot.com/2012/10/direct-pushpull-from -plastic-scm-to-git.html。オプション（SVNフレーバー）として完全に一元化されて機能しますが、すべてのマージ機能、グラフィックス、およびVStudio統合も備えています。
現在、私はVisualStudioを搭載したWindowsでGitを使用しています。しかし、私はLinuxでGitを最初に少し前に学びました。当初、私は当時働いていた1つのプロジェクトでgit-svnを実行していました。git-svnではすべてのGit機能を利用することはできませんが、Gitを使って自分の道を見つけ、Gitが開発に役立つと確信するのに十分でした。その後、そのリポジトリをSVNからGitに変換することにしました。
Gitの主な利点は、さまざまなワークフローに対応できる柔軟性があることだと思います。したがって、開発チームに最適なものを選択できます。集中型と分散型のどちらを選択するかは、2つの特定のワークフローの間ではなく、考えられるさまざまなワークフローの中から選択できます。SVNと同様の集中型ワークフローを維持することにした場合でも、Gitを使用することにはいくつかの利点があります。
まず、アップストリームとマージする前に変更をコミットします。SVNは、作業をコミットする前に「svnupdate」を実行するように強制します。これは、このマージ中にミスをした場合、作業を失う可能性があることを意味します。SVNでは、現在のマージ状態を破棄して再度やり直すことはできません。また、経験豊富な人に、コンピュータの作業ツリーに直接アクセスできない限り、重要なマージを手伝ってもらうことはできません。
一般に、コミットしてマージすると、変更が行われた実際の状態と、競合をどのように解決したかが示されるため、履歴がより真実になります。欠点は、履歴が線形ではなくなったことです。Gitを使用すると、「git pull --rebase」（デフォルトに設定できます）を実行することで線形履歴を保持できます。これにより、SVNの場合と同様に履歴が線形になります。
SVNの2番目の問題は、中央リポジトリに変更をコミットするときに、他の誰かがその間に変更を加えたかどうかがわからないことです。これらの変更が別のファイルに加えられた場合、SVNはChangeSetを受け入れます。その結果、SVNリポジトリには、誰もテストしていない新しい状態があります。通常、別のファイルに変更を加えても問題は発生しませんが、問題が発生する場合もあります。たとえば、1人の開発者はCヘッダーの一部の関数とそれが使用されるすべての場所を変更しますが、もう1人の開発者はこの関数の新しい使用法を新しいコードに追加します。したがって、各開発者が自分の変更をテストした場合でも、メインの開発ブランチで壊れた状態になる可能性があります。開発者は、誰かが「svn update」と言うまで、この破損にすぐに気付かないかもしれませんが、現時点では、この人は自分自身の変更を持っている可能性があります。
もう1つの便利なGit機能は、トランクに何もコミットせずにアイデアを試すことができることです。それがうまくいかない場合は、それを破棄することができ、誰も気付かないでしょう。他の人から何かを隠すのが好きというわけではありませんが、他の人に自分の作品を私の実験的なものとマージさせたくはありません。さらに、この実験的なコードを削除すると、他の変更と絡み合うため問題が発生します。したがって、SVNを使用する場合、唯一のオプションは、この機能に取り組んでいる間は何もコミットしないことです。ただし、問題が発生した場合に確認して二分する小さな論理的な手順ではなく、最後に巨大なパッチ爆弾が発生します。
ところで、git-bisectは、コード内のトリッキーなリグレッションと戦うのに非常に役立ちます。何かが壊れた場合、何が、なぜかは明らかではないかもしれません。したがって、この問題を引き起こしたコミットを見つける必要があり、git-bisectがこの作業に最適なツールです。
最後に、いくつかの状況をより適切に処理する方法を決定するためのオプションがさらにあります。たとえば、コアチームのメンバーは、変更を直接「トランク」（通常はGitでは「マスター」と呼ばれます）にプッシュできますが、新しく割り当てられた人にレビューなしで変更をプッシュさせたくない場合があります。したがって、同じ中央リポジトリ内の別のブランチに変更をプッシュするように指示してから、メンターに電子メールを送信してください。メンターは、変更が適切である場合は、この変更を確認してマージします。ブランチはGitで本当に安いので、それらを使用することを恐れてはいけません。短期間のトピックブランチがアップストリームにマージされると、通常、その名前は削除されるため、ブランチの名前空間が乱雑になることはありません。
これを考慮すると、現在ほとんどの開発はVisual Studioを備えたWindowsで行われており、Linuxからいくつかの単純なsvnコマンドを使用してアクセスする必要がありますが、GITはまだ良いオプションですか？
はい、そうです。Gitを使用すると、バージョン管理をバックアップシステム（ローカルでのみコミットし、完全な機能がある場合は公開）および探索作業（新しいブランチで新機能のプロトタイプを作成し、機能しない場合はブランチを削除）として使用できます。
Gitの分散型の性質は、集中型環境での作業を妨げるものではなく、単にそれを強制するものではありません。
切り替える価値はありますか？
私の意見では、そうです。私は多くのソース管理システムを使用してきましたが、分散型（当時はmercurial）に切り替えた後、作業への影響が大きかったため、次にプロジェクトでSVNを使用する必要があったときに、Mercurialをローカルにインストールしました。その上、「ローカルコミット」と痛みのないマージ機能のために。
GITが提供する他のどのような機能が私たちに利益をもたらしますか？
分岐すると、チーム全体に影響を与えることなく、不完全な作業を共有できます。つまり、メインブランチにまったく影響を与えることなく、レビュー、フィードバック、テスト、または貢献のために同僚に作業を送信できます。
ローカルコミットを使用すると、複数の機能を同時に操作できます（必要に応じて機能を切り替えるか、現在の作業を保存して別の機能に切り替えてから、簡単に元に戻すことができます）。また、バックアップポイントにバージョン管理システムを使用することもできます（コードがコンパイルされないか、コードがクリーンであるか、テストされているか、レビューされているかに関係なく、コードがコンパイルされない場合は他のすべての人に影響を与えることなく、何でもコミットできます）。
たとえば、他のタスクがないとき（または退屈しているとき、または少し時間があるとき）に作業するコードクリーンアップブランチがあります。ファイルまたはモジュールをクリーンアップするときにのみ、サーバーにプッシュします。
（ローカル）分岐を使用すると、チームの他のメンバーが「コミットするまで何もしない」ことなく、コードベース全体（またはコードベースの大部分）に影響を与える変更に取り組むことができるため、同期中にマージの競合が発生することはありません。
別の側面もあります。SVNでは、不完全なコードを追加すると、奇妙な#ifdef FEATURE_NAMEブロック内に配置する必要があります。これにより、コードが完全でなくても、他の人が半分実装された機能を回避できます。gitを使用すると、必要に応じて不完全な変更をブランチ（ローカルまたは集中型）で保持できるため、これは必要ありません。これにより、コードの無駄が最小限に抑えられます。
私は現在、高度に集中化されたワークフローを企業に実装しています。そうです、Gitはその設定で正常に機能します。
唯一の問題は、中央サーバーがgit（プッシュ/プル/クローン）操作を許可または拒否するために必要な適切な認証および承認レイヤーを追加することです。
詳細については、「分散バージョン管理システムとエンタープライズ-良い組み合わせですか？」を参照してください。
gitは非常に柔軟です。集中型または分散型の両方で使用できます。それは本当にワークフローについてです。すべての開発者を同じページに配置したい場合は、全員が定期的にプッシュ/プル/フェッチする必要があります。githubには、更新をユーザーに警告するための優れた通知機能が多数あります（メールやAtomフィードなど）。私たちは仕事でプライベートリポジトリの料金を支払い、フィードを頻繁に使用します。