誰もがGitを集中的に使用するのはなぜですか？

私は過去2つの会社でGitをバージョン管理に使用しました。私が聞いたところでは、企業の約90％が他のバージョン管理システムよりもGitを使用しているようです。

Gitの最大のセールスポイントの1つは、Gitが分散化されていることです。つまり、すべてのリポジトリが同等です。中央リポジトリ/真実の源はありません。これはLinus Torvaldsが擁護した機能でした。

しかし、すべての企業がSVNやCVSを使用するのと同じように、Gitを集中的に使用しているようです。サーバー（通常はGitHub）には、常に中央リポジトリがあり、人々はそこからプルし、プッシュします。Gitを本来の目的である分散化された方法で使用している人、つまり他の同僚のリポジトリを適切に押したり引いたりしている人を見たことはありません（確かに限られた経験）。

私の質問は：

1. Gitの分散ワークフローを実際に使用しないのはなぜですか？
2. 分散した方法で機能する能力は、最新のバージョン管理にとっても重要ですか？

編集

私は元の質問で正しい口調に出会えなかったことに気付きました。分散バージョン管理システム（DVCS）が明らかに優れているのに、なぜ誰もが中央集権的に機能するのかと私が尋ねているように聞こえました。実際には、私が言いたいことは、DVCSには何のメリットもありません。しかし、実世界は私の見解に同意しているように見えますが、私はしばしば人々がその優位性を説くのを聞きます。

ああ、しかし実際には分散型でgitを使用しています！

マインドシェアにおけるgitの前身であるsvnを比較しましょう。Subversionには、唯一の「レポ」、1つの真実のソースがありました。あなたがコミットしたとき、それは他のすべての開発者もコミットしていた単一の中央リポジトリに対してでした。

この種の方法は機能しましたが、多くの問題を引き起こしました。最大の問題は恐ろしいマージ競合です。これらは、迷惑なものから悪夢のような解決までどこにでもあることが判明しました。そして、1つの真実の源で、彼らは解決されるまでみんなの仕事を金切り声で止めるという厄介な習慣を持っていました。マージの競合は確かにgitに存在しますが、作業を停止するイベントではなく、はるかに簡単で迅速に解決できます。一般的には、全員ではなく、競合する変更に関係する開発者のみに影響します。

次に、単一障害点全体と、それに伴う付随する問題があります。中央のsvnレポジトリが何らかの理由で死んだ場合、バックアップから復元できるまですべてがねじ込まれ、バックアップがなかった場合は、すべて二重にねじ込まれます。しかし、「中央」のgitリポジトリが停止した場合、バックアップから復元することも、CIサーバー、開発者のワークステーションなどにあるリポジトリの他のコピーのいずれかから復元することもできます。そして、各開発者はリポジトリの第一級のコピーを持っています。

一方、gitリポジトリはそれ自体がファーストクラスのリポジトリであるため、コミットすると、コミットはローカルリポジトリに移動します。それらを他の人や真実の中心と共有したい場合は、リモートへのプッシュで明示的にこれを行う必要があります。他の開発者は、svnを絶えずチェックして、誰かがそれを台無しにする何かをしたかどうかを確認するのではなく、都合の良いときにそれらの変更をプルダウンできます。

他の開発者に直接プッシュするのではなく、別のリモートリポジトリを介して間接的に変更をプッシュするという事実は重要ではありません。私たちの観点からの重要な部分は、レポのローカルコピーがそれ自体でレポであることです。SVNでは、真理の中心的な源はシステムの設計によって実施されます。gitでは、システムにはこの概念さえありません。真実の源がある場合、それは外部で決定されます。

ビルドサーバは（あなたがするとされている CIを使用して、右？）ビルドを作成し、どこから引っ張っていますか？確かに、主張できる統合ビルドには「1つの真のレポ」は必要ありませんが、確かにディストリビューションビルド（つまり、お客様に提供するもの）は必要です。

つまり、断片化。1つのレポを「the」レポとして指定し、プルリクエストを審査する保護者を任命すると、「ソフトウェアビルドを提供してください」または「チームに新しいのですが、コードはどこにありますか？」というリクエストを満たす簡単な方法があります。

DVCSの強みは、ピアツーピアの側面ではなく、階層的であるという事実です。ワークスペースを変更し、ローカルにコミットします。機能が完成したら、コミットをマージしてリモートにプッシュします。そうすると、プルリクエストを作成し、プロジェクト管理者がそれをOne Trueリポジトリにマージする前に、誰でも私の暫定コードを確認したり、フィードバックを提供したりできます。

従来のCVCSでは、コミットするかしないかのいずれかです。これは一部のワークフロー（別のプロジェクトに両方のVCSタイプを使用）では問題ありませんが、パブリックプロジェクトまたはOSSプロジェクトでは一見フラットです。重要な点は、DVCSには複数のステップがあり、より多くの作業が必要ですが、チェックイン対象の可視性を高める組み込みプロセスにより、見知らぬ人からのコードを統合するためのより良い方法を提供します。より良いコード共有メカニズムを提供しながら、プロジェクトの現在の状態のゴールドスタンダードを持っています。

「全員」をどのように定義するのかわかりませんが、私のチームには「サーバー上の中央リポジトリ」があり、その中央リポジトリを経由せずに他の同僚のリポジトリからプルすることもあります。これを行うとき、私たちはまだサーバーを経由します。なぜなら、場所に関するパッチを電子メールで送信するのではなく、中央レポ経由では選択しないからです。これは通常、グループが特定の機能で共同作業を行っており、互いに最新の状態を保ちたいが、まだその機能を全員に公開することに興味がない場合に発生します。当然、私たちは秘密のサイロ労働者ではないので、これらの状況は長続きしませんが、DVCSは最も便利なことを何でも行える柔軟性を提供します。好みに応じて機能ブランチを公開できます。

しかし、90％以上の時間、確かに、中央レポを経由します。特定の変更や特定の同僚の作業を気にしないときは、Nのそれぞれから変更を個別にプルするよりも、「中央レポで吟味されたすべての同僚の変更」をプルする方がより便利で、拡張性が高い同僚。DVCSは、「メインリポジトリからプル」が最も一般的なワークフローであることを防止しようとはしていません。それが唯一の利用可能なワークフローであることを防止しようとしています。

「分散」とは、gitソフトウェアに関する限り、すべてのリポジトリが技術的に同等であることを意味しますが、開発者と当社のワークフローに関する限り、すべてのリポジトリが同等の意味を持つわけではありません。クライアントまたは実稼働サーバーにリリースする場合、そのために使用するレポは、ラップトップで1人の開発者のみが使用するレポとは異なる意味を持ちます。

「真に分散化」が「特別なリポジトリがない」ことを意味する場合、Linusがチャンピオンに意味することはないと思います。実際のところ、彼は物事の壮大な計画においてより重要な特別なリポジトリを維持しています昨日作成したLinuxのランダムクローン。小さなパッチを開発するためだけに使用し、パッチを受け入れたら削除する予定です。git私のリポジトリよりもレポに特権を与えませんが、ライナスはそれを特権にしています。彼の「Linuxの現状」は私のものではありません。自然に変化する傾向がありますLinusを経由します。集中型VCSに対するDVCSの強みは、事実上のセンターが存在してはならないということではなく、誰もがマージできるため（競合が許可されているため）、変更がセンターを経由する必要がないことです。

DVCSシステムもされて強制的に、彼らは分散型であるため、ローカルに何かをするために、あなたは必ずしも完全な履歴（つまり、レポ）を持っていなければならないという事実を中心に基づいて、特定の便利な機能を提供するために、、。しかし、考えてみると、読み取り専用操作の履歴全体を保持するローカルキャッシュで中央集中型VCSを設定できなかった根本的な理由はありません（Perforceにはこのモードのオプションがあると思いますが、しかし、Perforceを使用したことはありません）。または、原則gitとして、.git/SVNの「機能」をエミュレートするためにリモートマウントされたファイルシステム上のディレクトリ。ネットワーク接続がない場合は機能しません。事実上、DVCSは、集中型VCSで逃げることができるよりも強い配管を強制します。これは（非常に歓迎すべき）副作用であり、DVCS設計の動機付けに役立ちましたが、この技術レベルでの責任の分散は、すべての人間の責任を完全に分散させることとは異なります。

DVCSの性質に関する興味深い点は、他の人がそれを分散的に使用している場合、彼らがあなたと直接対話しない限り、あなたはおそらくそれを知らないでしょう。あなたが断言できる唯一のことは、あなたとあなたの直接のチームメイトがこの方法でgitを使用しないということです。これは、会社全体のポリシーを必要としません。それでは、なぜgitを分散化された方法で使用しないのでしょうか？

編集に対処するには、実際の集中型バージョンコントロールを使用して違いを評価する経験が必要です。微妙に見えるかもしれませんが、それらは広範にわたるためです。これらは、VCSを集中管理したときにできなかった、チームが実際に仕事で行っているすべてのことです。

• 各マイクロサービスの「中央」レポジトリへのコミットアクセス権を持つコア開発者の非常に小さなリストを用意します。他のすべてのユーザーは、フォークを使用してプルリクエストで送信できます。
• はるかに頻繁にコミットできます。通常は1日1回または2回ではなく、1時間に数回です。
• 何らかの理由でブランチを作成して同僚と一時的に調整し、1日に数回プッシュしてそこからプルし、大きなグループと共有する準備ができたらそれを押しつぶすことができます。従来のCVCSでこのようなものの一時的なブランチを作成する許可を得るのがどれほど難しいかご存知ですか？

それを言うのは古く聞こえるかもしれませんが、あなたはそれをどれだけ簡単にできるのか本当に分かりません。

あなたの質問は、（理解可能な）常につながっている考え方から来ていると思います。 すなわち、中央の「真実」ciサーバーは常に（またはほぼ常に）利用可能です。これはほとんどの環境で当てはまりますが、私はこれとは程遠い少なくとも1つで働いてきました。

私のチームが数年前に取り組んだ軍事シミュレーションプロジェクト。 すべてのコードは、（我々は> US $ 1Bコードベースを話している）に持っていたマシンであること（あなたがいない場合は、法律/国際協定によって、ダークスーツの男性が来て）物理的から分離された任意のインターネット接続。これは、私たちがそれぞれ2台のPCを持っている通常の状況を意味しました。1台はコードの作成/実行/テスト用、もう1台はGoogleのもの、Eメールなどのチェック用です。また、これらのマシンのチーム内にはローカルネットワークがあり、明らかにインターネットに接続されていませんでした。

「真理の中心的源」は、軍隊の基地にある機械であり、すべて軽量の地下窓のない部屋（強化された建物、やだやだ）にありました。そのマシンにはインターネット接続もありませんでした。

定期的に、gitレポ（コードのすべての変更を含む）を備えたドライブを軍基地（数百キロメートル先にある）に（物理的に）移送するのは誰かの仕事です。

さらに、多くのチームがある非常に大規模なシステムでは。それらは一般にそれぞれ独自の「中央」レポを持ち、それは実際の（神ティア）「中央」レポに戻ります。コードで同じハードドライブgitリポジトリダッシュを行った請負業者が少なくとも1人いることは知っています。

また、Linuxカーネルの規模で何かを検討する場合...開発者は、Linus自身にプルリクエストを送信するだけではありません。それは基本的にレポの階層です-それぞれが誰か/あるチームにとって「中心」でした/「中心」です。

gitの切断された性質は、環境で使用することができることを意味する接続モデルソース管理ツール（すなわち、いずれかのSVN）を使用することができなかった-として、または容易に使用することができませんでした。

最終的には、製品を構築しています。この製品は、ある時点でのコードを表します。そのため、コードはどこかで合体する必要があります。自然なポイントは、製品が構築されるciサーバーまたは中央サーバーであり、この中央ポイントがgitリポジトリであることは理にかなっています。

DVCSの分散的な側面は、オープンソース開発では常に分岐の形で現れます。たとえば、私が貢献したプロジェクトの一部は元の作者によって放棄され、現在はメンテナーが特定の機能を相互にプルするフォークの束を持っています。一般的にさえ、OSSプロジェクトは、ランダムな人々にグラウンドトゥルースレポジトリへのアクセスを許可するのではなく、プルリクエストを介して外部からの寄付を受け付けます。

特定の公式リリースで具体的な製品を構築する場合、これはあまり一般的な使用例ではありませんが、F / OSSの世界では例外ではなく標準です。

なぜ誰もがgitを集中的に使用するのですか？

会ったことはありませんが、どうしてみんなと言うのですか？;）

第二に、GitにはあるがCVSやSVNにはないその他の機能があります。たぶん、これはすべての人にとって唯一の機能でなければならないということをあなたが仮定しているだけでしょう。

確かに多くの人がCVSやSVNのように集中化して使用するかもしれません。ただし、分散VCSに本来備わっている他の機能も忘れないでください。すべてのコピーは多かれ少なかれ「完全」であり（すべてのブランチと完全な履歴が利用可能）、サーバーに接続せずにすべてのブランチをチェックアウトできます。

私の意見では、これは忘れてはならない別の機能です。

すぐに使用できるCVSとSVNでこれを行うことはできませんが、Gitは問題なく以前のものと同様に集中的に使用できます。

そのため、変更をコミットし、進行中の作業をまとめてスカッシュしてから、作業をフェッチしてメイン開発ブランチにリベースすることができます。

Gitですぐに使用できるその他の機能：

• コミットに暗号的に署名する
• リベース（コミットの順序変更とスカッシュ、メッセージだけでなくコミットの編集）
• さくらんぼ狩り
• 歴史を二分する
• ローカルブランチとスタッシングの変更（ウィキペディアでは「棚」と呼ばれます）

ウィキペディアの次の3つの表も参照してください-バージョン管理ソフトウェアの比較：

• 特徴

• 基本的なコマンド

• 高度なコマンド

繰り返しますが、多分、分散型の方法は、それを人々に使用させる機能だけではありません。

1. Gitの分散ワークフローを実際に使用しないのはなぜですか？

Bitbucked、GitHubなどでより大きなプロジェクトに貢献したり、ホストしたりする人は誰でも正確にそれを行います。メンテナーは「メイン」リポジトリを保持し、貢献者はクローンを作成し、コミットしてからプル要求を送信します。

企業では、小規模なプロジェクトやチームであっても、モジュールを外部委託し、変更を事前にレビューせずに外部が神聖な開発ブランチを変更したくない場合、分散ワークフローがオプションになります。

2. 能力は分散した方法で機能し、現代のバージョン管理にとっても重要です...

いつものように：要件に依存します。

いずれかのポイントが該当する場合は、分散VCSを使用します。

• 履歴をコミットまたはオフラインでナビゲートしたい（つまり、休暇中に山小屋のサブモジュールを仕上げる）
• 中央リポジトリを提供しますが、変更をレビューするために「真の」リポジトリを分けておきたい（つまり、大きなプロジェクトや分散したチームの場合）
• 中央レポへの直接アクセスを防ぎながら、2つ目の履歴と同様に、履歴全体とブランチを時々（コピー）提供したい
• リモートで保存したり、専用のリポジトリを設定したりせずに何かをバージョン管理したい（特にGitでは、git init .何かをバージョン管理する準備ができているだけで十分です）

いくつかありますが、4つあれば十分です。

...またはそれはちょうどいい音ですか？

もちろん、いいですね-初心者向け。

柔軟性は呪いであると同時に祝福でもあります。Gitは非常に柔軟であるとして、それはほとんど常にですはるかに一般的な状況に柔軟すぎます。特に、ほとんどのGitプロジェクトはLinuxではありません。

そのため、Gitを実装する際に、理論上の柔軟性の一部を取り除くことが賢明な選択です。理論的には、リポジトリは任意のグラフを形成できますが、実際には通常の選択はツリーです。グラフ理論を使用すると、明確な利点を確認できます。リポジトリのツリーでは、2つのリポジトリが1つの祖先を共有します。ランダムグラフでは、祖先のアイデアは存在しません！

ただし、gitクライアントは、ほぼ確実にデフォルトで「単一の祖先」モデルになります。そして、ノードが単一の祖先を持つグラフ（ルートノードを除く）は、まさにツリーです。したがって、gitクライアント自体はデフォルトでツリーモデルを使用するため、リポジトリが集中管理されます。

ビジネスロジックは、集中型サーバーに報います。ほぼすべての現実的なビジネスシナリオでは、集中型サーバーがワークフローの基本的な機能です。

DVCSを実行する能力があるからといって、主なワークフローをDVCSにする必要があるわけではありません。仕事でgitを使用するときは、分散ビットが物事の進行を維持するために不可欠である奇妙な奇妙なケースを除いて、中央集権的に使用します。

物事の分散面は複雑です。通常、物事をスムーズかつ簡単に保ちたいと思うでしょう。ただし、gitを使用することで、分散サイドにアクセスして、今後発生する可能性のある厄介な状況に対処できるようになります。

同僚が私のマシンのgitリポジトリからプルするには、バックグラウンドタスクとしてルートレベルで実行されているgitデーモンが必要です。私は自分のコンピューターで、または会社が提供するラップトップで実行しているデーモンに非常に不安を感じています。最も簡単な解決策は「NO」です！同僚が私のマシンのgitリポジトリからプルするには、インターネットアドレスを修正する必要があります。私は旅行し、自宅で仕事をし、時々オフィスで働きます。

一方、企業サイトへのVPN接続と中央レポへのブランチのプッシュには1分もかかりません。オフィスにいる場合は、VPNで接続する必要さえありません。私の同僚はそのブランチから簡単に引き出せます。

第三に、私のローカルgitリポジトリはフル機能のリポジトリです。私は、どこか真ん中を30,000フィート上空を飛行する飛行機で作業している場合でも、物事を混乱させるときに、新しい作業をコミットし、実験的な作業のために新しいブランチを作成し、作業を元に戻します。一元化されたバージョン管理システムでそれを試してください。

複雑：

中央リポジトリでは、一般的なワークフローは次のようになります

branch off from the central master branch
change the code
test
possibly go back to changing the code
commit
merge any new changes from the central master branch
test
possibly go back to changing the code
merge changes into the central master branch and push

O（1）の開発者数に関する複雑さ。

代わりに各開発者が独自のマスターブランチを持っている場合、開発者0の場合：

branch off from master branch 0
merge from master branch 1
...
merge from master branch N-1
change the code
test
possibly go back to changing the code
commit
merge any changes from master branch 0
merge any changes from master branch 1
...
merge any changes from master branch N-1
test
possibly go back to changing the code
merge changes into master branch 0

ピアツーピアアプローチはO（N）です。

一貫性：

次に、アリスのマスターブランチとボブのマスターブランチの間にマージの競合があるかどうかを検討します。N人の開発者はそれぞれ、異なる方法で競合を解決できます。結果：カオス。最終的な一貫性を実現する方法はありますが、それが実現するまで、開発者のあらゆる種類の時間が無駄になります。

シンプル：

企業は、ワークフローが一元化された集中型組織です。

すべてのプログラマーには上司がいて、CTOまでは上司などがいます。CTOは技術的な真実の究極の源です。会社が使用するツールが何であれ、この指揮系統を反映する必要があります。会社は軍隊のようなものです-民間人に将軍を投票させることはできません。

GITは、企業に役立つ機能（コードレビューのプルリクエストなど）を提供し、それだけでGITに切り替えます。分散化された部分は単に必要のない機能であるため、無視されます。

あなたの質問に答えるために：分散部分は分散環境、例えばオープンソースで確かに優れています。結果は、話している人によって異なります。Linus Torvaldsはまさにあなたのキュービクルラットではありません。そのため、Gitのさまざまな機能がGitHub中心の会社よりも重要です。

たぶん、彼の給与処理が集中化されているからだろう。だから、支払いを受けたいなら、中央の人を幸せにしておかなければならない。

たぶんそれは私たちが1つの製品を作成しているからだと思うので、顧客のためにソフトウェアのマスターコピーが必要です。

たぶん、多くの異なるマシンに接続するよりも、プログラマーが1つの場所に行って全員の変更を取得する方がずっと簡単だからでしょう。

バグデータベースが集中化されており、コードとの同期を維持する必要があるためかもしれません。

問題が発生するまで、集中化するのは素晴らしいことです…..

Gitは分散システムであるため、最新のリポジトリから新しいセンターを低コストで作成できます（リポジトリをネットワークに公開するだけです）。また、Gitを使用すると、開発者のマシンのリポジトリから古いバックアップを更新できるため、センターの復旧が容易になります。

ネットワークがダウンしているときにリポジトリのローカルコピーでマージなどを実行できることは素晴らしいことですが、分散システムは必要ありません。すべてのデータのローカルコピーを保持するシステムが必要なだけです。同様に、飛行などでコードをチェックインする場合

1日の終わりには、配布にかかる費用はほとんどかからず、メリットもあります。配布のコストの大部分は、ブランチなどを追跡するのに必要な領域にあります。ほとんどの企業で使用するシステムを設計する場合、ソースコードの一元管理として、配布用に設計することはできません。明らかに主要な「ユースケース」です。