なぜ誰もがGitを一元的に使用するのですか？
過去2社でバージョン管理にGitを使用しました。私が聞いたところによると、企業の約90％が他のバージョン管理システムよりもGitを使用しているようです。
Gitの最大のセールスポイントの1つは、分散型であることです。つまり、すべてのリポジトリが同等です。中央リポジトリ/真の情報源はありません。これは Linus Torvalds が擁護した機能でした。
しかし、SVNやCVSを使用するのと同じように、すべての企業がGitを集中的に使用しているようです。サーバー（通常はGitHub）には常に中央リポジトリがあり、そこからプルしたりプッシュしたりします。 （確かに限られた経験の中で）Gitを意図したとおりに分散化された方法で使用すること、つまり、他の同僚のリポジトリに適するようにプッシュしたりプルしたりすることを見たことも聞いたこともありません。
私の質問は：
- なぜ人々は実際にGitの分散ワークフローを使用しないのですか？
- 分散した方法で機能する能力は、最新のバージョン管理にとっても重要ですか、それとも単にいい音ですか？
編集する
元の質問では正しい調子に出くわしていないことに気付きました。 分散バージョン管理システム （DVCS）が明らかに優れているのに、なぜ誰もが集中管理された方法で作業するのではないかと私が尋ねているように思えました。実際、私が言いたかったのは、DVCSには何のメリットもないです。それでも、現実が私の意見に同意しているように見える一方で、人々がその優位性を説くのをよく耳にします。
ああ、でも実際にはare分散型でgitを使用しています！
Gitの前身であるマインドシェアsvnを比較してみましょう。 Subversionには、1つの「レポ」、つまり1つの真の情報源しかありませんでした。あなたがコミットをしたとき、それは他のすべての開発者が同様にコミットしていた単一の中央レポジトリに対するものでした。
この種の問題は解決しましたが、多くの問題が発生しました。最大の問題は恐ろしいマージの競合です。これらは、迷惑なものから悪夢のようなものまで解決することができました。そして、真実の根源が1つあるため、彼らは解決するまで全員の仕事を金切りにさせるという厄介な癖を持っていました。マージの競合は確かにgitに存在しますが、それらは作業を停止するイベントではなく、解決がはるかに簡単で高速です。通常、全員ではなく、競合する変更に関与している開発者のみに影響します。
次に、全体的な単一障害点と、それに伴う問題が発生します。中央のsvnリポジトリがなんらかの理由で停止した場合、バックアップから復元できるようになるまですべてが台無しになり、バックアップがない場合はすべて二重に台無しになります。ただし、「中央」のgitリポジトリが停止した場合は、バックアップから、またはCIサーバー、開発者のワークステーションなどにあるリポジトリの他のコピーからでも復元できます。これは、分散されているため正確に実行できます。そして、各開発者はレポのファーストクラスのコピーを持っています。
一方、git repo isそれ自体がファーストクラスのリポジトリであるため、コミットすると、コミットはローカルリポジトリに送られます。それらを他の人や中心的な情報源と共有したい場合は、リモートへのプッシュで明示的に行う必要があります。他の開発者は、都合の良いときにこれらの変更を引き下げることができます。誰かがそれらを台無しにする何かを行ったかどうかを確認するために常にsvnをチェックする必要はありません。
直接を他の開発者にプッシュする代わりに、別のリモートリポジトリを介して間接的に変更をプッシュするという事実は、それほど重要ではありません。私たちの観点からの重要な部分は、リポジトリのローカルコピーがそれ自体がリポジトリであることです。 svnでは、真実の中心的な情報源はシステムの設計によって強制されます。 gitでは、システムにこの概念さえありません。真実の根源がある場合、それは外部で決定されます。
ビルドサーバー（CIを使用するareを使用している場合）がビルドを作成するとき、どこからプルするのですか？確かに、あなたが主張できる統合ビルドは「1つの真のリポジトリ」を必要としませんが、確かにディストリビューションビルド（つまり、お客様に提供するもの）は必要です。
つまり、断片化です。 1つのリポジトリを「the」リポジトリとして指定し、プルリクエストを精査する保護者を任命すると、「ソフトウェアビルドを提供する」または「チームに初めて参加します。コードはどこですか？」というリクエストを満たす簡単な方法があります。
DVCSの長所は、ピアツーピアの側面ではなく、階層的であるという事実です。ワークスペースを変更してから、ローカルにコミットします。機能が完成したら、コミットをマージしてリモートにプッシュします。そうすれば、プルリクエストを作成してプロジェクト管理者がそれをOne Trueリポジトリにマージする前に、だれでも私の暫定コードを確認したり、フィードバックを提供したりできます。
従来のCVCSでは、コミットするかしないかを決めます。これは一部のワークフローでは問題ありません（私はさまざまなプロジェクトで両方のVCSタイプを使用します）が、パブリックプロジェクトまたはOSSプロジェクトの場合は面倒です。重要な点は、DVCSには複数のステップがあり、より多くの作業が必要ですが、組み込みプロセスを通じて見知らぬ人からのコードを統合するためのより良い方法を提供し、チェックインされているものに対する可視性を向上させます。より良いコード共有メカニズムを提供しながら、プロジェクトの現在の状態のそのゴールドスタンダードを持っています。
「誰でも」の定義方法はわかりませんが、私のチームには「サーバー上の中央リポジトリ」があり、-alsoはその中央リポジトリを経由せずに他の同僚のリポジトリから随時プルします。これを行うときは、場所に関するパッチを電子メールで送信せず、中央のリポジトリ経由ではないため、サーバーを経由します。これは通常、グループが特定の機能について共同作業を行っており、互いに最新の状態を維持したいが、まだ機能を全員に公開することに関心がない場合に発生します。当然のことながら、私たちは秘密のサイロ労働者ではないので、これらの状況は長くは続きませんが、DVCSは最も便利なことを何でも行える柔軟性を提供します。機能ブランチを公開することも、好みに応じて公開しないこともできます。
しかし、90％以上の確率で、中央レポを経由します。特定の変更や特定の同僚の作業を気にしない場合は、Nのそれぞれから変更を個別にプルするのではなく、「中央リポジトリで精査されたすべての同僚の変更」をプルする方が便利であり、スケーリングも優れています。同僚。 DVCSは、「pull from main repo」が最も一般的なワークフローであることを防止しようとするのではなく、利用可能な唯一のワークフローであることを防止しようとしています。
「分散」とは、gitソフトウェアに関する限り、すべてのリポジトリが技術的に同等であることを意味しますが、開発者とワークフローに関する限り、それらすべてが同等の意味を持つというわけではありません。クライアントまたは本番サーバーにリリースする場合、そのために使用するリポジトリは、1人の開発者がラップトップで使用するリポジトリとは異なる意味を持ちます。
「本当に分散型」が「特別なリポジトリがない」という意味の場合、実際には彼がdoes特別なリポジトリを維持していることを考えると、Linusがチャンピオンに意味しているとは思わないare私が昨日作ったLinuxのランダムなクローンよりも重要なことです。小さなパッチを開発して、パッチを受け入れたらそれを削除することだけを計画しています。 gitは私のリポジトリに私の権限を付与していませんが、Linus doesは権限を付与しています。彼の「Linuxの現状」はそうではありません。したがって、自然にtendを変更してLinusを通過します。集中型VCSに対するDVCSの強みは、事実上のセンターが存在してはならないということではありません。（競合が許可されれば）誰でも何でもマージできるので、変更がセンターを経由する必要がないということです。
DVCSシステムはforcedでもあり、分散化されているため、何かを行うにはローカルで完全な履歴（つまり、リポジトリ）をローカルに保持する必要があるという事実に基づいた便利な機能を提供します。しかし、それについて考える場合、期限切れの許可された読み取り専用操作の履歴全体を保持するローカルキャッシュで集中型VCSを構成できなかった根本的な理由はありません（Perforceにはこのモードのオプションがあると思いますが、ただし、Perforceを使用したことはありません）。または原則として、gitを.git/リモートマウントされたファイルシステム上のディレクトリ。ネットワーク接続がない場合に機能しないSVNの「機能」をエミュレートするため。事実上、DVCSは、集中型のVCSで避けられないよりも配管をより強固にします。これは（大歓迎）の副作用であり、DVCS設計の動機付けに役立ちましたが、このtechnicalレベルでの責任の分散は、すべてのhumanの責任を完全に分散化することと同じではありません。
DVCSの性質についての興味深いことは、他の人々が分散してそれを使用している場合、彼らが直接あなたと対話していない限り、おそらくそれを知らないでしょう。あなたが決定的に言うことができる唯一のことはあなたであり、あなたの直接のチームメイトはこのようにgitを使用しません。これは全社的な方針を必要としません。だから私はあなたに尋ねます、なぜあなた分散型の方法でgitを使わないのですか？
編集に対処するには、違いを理解するために、実際の集中バージョン管理での作業経験が必要になる場合があります。これは、微妙に見えるかもしれませんが、それらは広範囲にわたるためです。これらは、実際にVCSを集中管理していたときに実行できなかった、私のチームが実際に行うすべてのことです。
- 各マイクロサービスの「中央」リポジトリへのコミットアクセスを持つコア開発者の非常に少数のリストを用意します。他の誰もがフォークから作業し、プルリクエストを介して送信できます。
- コミットできますmuchより頻繁に、通常は1時間に数回、1日に1回または2回。
- 何らかの理由でブランチを作成して一時的に同僚と調整し、1日に数回ブランチにプッシュしてプルし、より大きなグループと共有する準備ができたらスカッシュします。従来のCVCSでこのようなものの一時的なブランチを作成する許可を取得するのがどれほど難しいか、何か考えはありますか？
それを言うために古く聞こえる危険を冒して、あなたは本当にそれがどれほど簡単であるかを知りません。
あなたの質問は（理解できる）常につながっている考え方から来ていると思います。 i.e。中央の「真実」CIサーバーは常に（またはほぼ常に）使用可能です。これはほとんどの環境に当てはまりますが、私はこれとはかけ離れた少なくとも1つの環境で作業しました。
私のチームが数年前に取り組んだ軍事シミュレーションプロジェクト。 Allコード（> 10ドルのコードベースを話している）がしなければならなかった（法律/国際協定により、ダークスーツの男性は、しないでください物理的にanyインターネット接続から隔離されています。これは、私たちがそれぞれ2台のPCを持っているという通常の状況を意味しました。そして、これらのマシンのチーム内にはlocalネットワークがあり、明らかにインターネットに接続されていません。
「真実の中心的情報源」は、すべてのシンダーブロックの地下の窓のない部屋（強化された建物、yada-yada）の軍基地の機械でした。そのマシンまたはインターネット接続がありませんでした。
定期的に、ドライブを（物理的に）gitレポ（コードのすべての変更を含む）を使って（数百キロ離れた）陸軍基地に（物理的に）輸送するのは誰かの仕事です。
さらに、lotsのチームがあるvery大規模システムでは、それらは通常、それぞれ独自の「中央」レポを持ち、それが実際の（神層）「中央」中央レポに戻ります。同じハードドライブgit repoダッシュをコードで実行した他の請負業者が少なくとも1人いることを知っています。
また、Linuxカーネルの規模で何かを検討している場合...開発者は、Linus自身にプルリクエストを送信するだけではありません。それは本質的にレポの階層です-それぞれは誰か/いくつかのチームにとって「中心的」でした/されました。
Gitの切断された性質は、それがconnectedモデルソース管理ツール（ieSVNの1つ）を実行できない環境で使用できることを意味します中古-または簡単に使用できませんでした。
最終的には、製品を構築しています。この製品は、ある時点でのコードを表します。その場合、コードは合体する必要がありますどこか。自然なポイントは、製品が構築されているciサーバーまたは中央サーバーであり、この中央ポイントがgitリポジトリであることは理にかなっています。
DVCSの分散された側面は、オープンソース開発では常にフォークの形で現れます。たとえば、私が寄稿しているプロジェクトの一部は、元の作者によって放棄されており、メンテナーが特定の機能を相互にプルするフォークがたくさんあります。一般的にさえ、OSSプロジェクトは、ランダムな人々にグラウンドトゥルースリポジトリへのプッシュアクセスを許可するのではなく、プルリクエストを介して外部の貢献をします。
これは、特定の公式リリースを使用して具体的な製品を構築する場合の一般的な使用例ではありませんが、F/OSSの世界では例外ではありません。
なぜ誰もが一元的にgitを使用するのですか？
私たちは会ったことがありません、あなたはなぜみんなと言うのですか？ ;）
次に、GitにはあるがCVSやSVNにはないその他の機能があります。 everyoneのonly featureでなければならないことを想定しているだけかもしれません。
確かに多くの人がCVSやSVNのように集中的に使用するかもしれません。ただし、本質的には分散型VCSに付属している他の機能を忘れないでください。すべてのコピーは多かれ少なかれ「完全」であり（すべてのブランチと完全な履歴が利用可能）、すべてのブランチはサーバーに接続せずにチェックアウトできます。
これは忘れてはならないもう1つの機能だと思います。
すぐに使えるCVSとSVNではこれを行うことはできませんが、Gitは以前のGitと同様に集中化して問題なく使用できます。
変更をコミットし、進行中のコミットをまとめてスカッシュし、作業をフェッチしてメインの開発ブランチにリベースすることができます。
Gitに付属しているその他の機能：
- コミットに暗号で署名する
- リベース（コミットの並べ替えとスカッシュ、メッセージだけでなくコミットの編集）
- さくらんぼ狩り
- 歴史を二分する
- ローカルブランチと隠し変更（ウィキペディアでは「シェルビング」と呼ばれています）
Wikipedia-バージョン管理ソフトウェアの比較 のこれら3つの表も参照してください。
繰り返しますが、おそらく、分散型の方法は、人々にそれを使用させる機能だけではありません。
- なぜ人々は実際にGitの分散ワークフローを使用しないのですか？
Bitbucked、GitHubなどでより大きなプロジェクトに貢献したり、ホストしたりする人は誰でも正確にそれを行います。メンテナは「メイン」リポジトリを維持し、コントリビュータはクローンを作成してコミットし、プルリクエストを送信します。
企業では、小さなプロジェクトやチームであっても、モジュールをアウトソーシングし、外部に変更を事前に確認させずに神聖な開発ブランチを変更させたくない場合は、分散ワークフローがオプションです。
- 分散バージョンで機能する能力は、最新のバージョン管理にとっても重要です...
いつものように：それは要件に依存します。
いずれかの点が当てはまる場合は、分散型VCSを使用します。
- オフラインで履歴をコミットまたはナビゲートしたい（休暇中に山小屋のサブモジュールを終了する）
- 中央リポジトリを提供するが、変更をレビューするために「真の」リポジトリを分けておきたい（つまり、大きなプロジェクトまたは分散チームの場合）
- 中央リポジトリへの直接アクセスを防止しながら、履歴全体とブランチ（のコピー）を時々提供したい（2番目のものと同様）
- リモートで保存したり、専用のリポジトリを設定したりすることなく、バージョン管理をしたい（特にGitでは単なる
git init .何かをバージョン管理する準備ができるのに十分な人）
さらにいくつかありますが、4つで十分です。
...それともいい音だけですか？
もちろんそれはいいね-初心者のために。
柔軟性は呪いであり、祝福でもあります。また、Gitは非常に柔軟であるため、ほとんどの場合farは一般的な状況には柔軟すぎます。特に、ほとんどの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を中心とした会社よりもGITのさまざまな機能が重要です。