63

Gitは分散型システムであると想定されていますが、Googleで見つけたすべてのチュートリアルとベストプラクティスワークフローでは、サーバー（通常はGitHub、または独自にセットアップ）を使用することをお勧めします。

私は小規模な個人プロジェクト（2〜3人）にgitを使用しています。ここで、チームメンバーのマシン間で変更を直接同期するためのベストプラクティスワークフローを見つけることができます。

あるいは、なぜこれを避けて代わりに「中央」サーバーをセットアップする必要があるのか​​についての説得力のある議論は何ですか？

4

7 に答える 7

43

「サーバー」の意味によって異なります。Gitは中央サーバーがなくても問題なく動作しますが、多くのチームは中央リポジトリがあると便利だと感じています。

「サーバー」が「サーバーソフトウェアのインストール」を意味する場合、gitは、sshを介して、またはファイルシステム上で、特別なソフトウェアがなくても（中央リポジトリであるかどうかにかかわらず）機能します。

可能なワークフローについては、このドキュメントを参照してください

共通リポジトリを使用したワークフロー

多くの人が使用するワークフローは、すべての開発者が変更を共通のリポジトリに「プッシュ」（送信）し、そのリポジトリからすべての変更を取得することです。このようなもの：

  • 開発者Aが中央にプッシュ
  • 開発者Bが中央にプッシュ
  • 開発者Cがプル（AとBから変更を取得）
  • 開発者Aがプル（Bから変更を取得）
  • ..。

この場合、中央リポジトリは、開発者のコ​​ンピューターの1つ、github、またはその他の場所に置くことができます。

メールによるワークフロー

サーバーなしで、メールを使用するだけでgitを使用することもできます。この場合、フローは次のようになります。

  • 開発者Aは変更をメールとしてチームに送信します
  • 他の開発者は、電子メールからの変更を適用します

これは、半自動化された方法でも実行できます

中央サーバーなしのワークフロー

複数の「リモート」リポジトリを使用するようにgitを設定できます。注意点は、チェックアウトされているリポジトリ（つまり、誰かが作業している開発者のコ​​ピー）にプッシュしてはならないということです。したがって、この場合、フローは次のようになります。

  • 開発者Aが変更を加える
  • 開発者Bが変更を加える
  • 開発者CはAから変更をプルします
  • 開発者CはBから変更をプルします
  • 開発者BはAから変更をプルします
  • ..。
  • 誰もプッシュしてはいけません

私見このタイプのワークフローは、すぐに混乱と故障につながります。

于 2011-05-10T08:33:39.617 に答える
34

最初に行う必要があるのは、すでにどのようなワークフローがあるかを考え、それを処理するようにgitを構成することです。何かを稼働させたら、それを微調整できます。サーバーとして別のコンピューターをセットアップする必要はありません。中央リポジトリを使用することに慣れている場合は、誰もがプッシュできるベアリポジトリを作成するだけです。なぜローカルネットワーク上にないのですか？

中央リポジトリ：

mkdir foo.git
cd foo.git
git init --bare

あなたのレポ：

mkdir foo
cd foo
git init
// add files
git add .
git commit -m "Initial commit"
git remote add origin //path/to/central/repo/foo.git
git push origin master

その他のリポジトリ：

git clone //path/to/central/repo/foo.git

これで、誰でもマスターブランチから直接プッシュおよびプルできます。これはあなたが始めるのに十分なはずです。

于 2011-05-10T08:38:57.533 に答える
11

必ずしも物理サーバーのどこかにコピーを置く必要はありませんが、「祝福された」リポジトリをどこかに置くと役立つ場合があります。チームの1人（おそらくローテーション）に、人々の変更を収集して管理する責任を負わせます。最終として扱われる準備ができています。通常のリポジトリにブランチを保持するか、ローカルシステムに別のリポジトリを維持してマスターソースを保存することができます。

具体的な例として、LinuxとLinus Torvaldsを考えてみましょう。誰もがプッシュする中央リポジトリはありませんが、Linusは、「準備ができている」と見なすすべてのコードを含むリポジトリを維持しています（準備'）。そうすれば、どのコードが含まれているかの標準的な定義と、リリースが何であるかを定義する場所が得られます。

于 2011-05-10T09:44:11.083 に答える
9

中央サーバーを技術的な構成ではなく社会的な構成としてセットアップする必要があります。そうすることで、混乱する可能性なしに、最新の公式バージョンがどこにあるかを誰もが知ることができます。

于 2011-05-10T08:29:28.233 に答える
9

すでに述べたように、Gitは集中型サーバーがなくても非常にうまく機能します。ただし、中央サーバーを使用する理由は、他の開発者がローカルマシンにアクセスしなくてもプルできる機能が完了したら、コードをプッシュするための「常時オン」の場所を用意することです。

たとえば、現在私は3人の開発チームで働いています。私たちは皆ラップトップで働いています。お互いのマシンから引っ張るだけのワークフローが可能です。しかし、私が機能に取り組み、全員がオフィスを離れた後にチャンスを約束し、このシステムを見てもらいたい場合、私のラップトップがネットワーク上で利用可能でない限り、彼らは何もできません。彼らが私より早く現れた場合（彼らはいつもそうします）、彼らは私のラップトップがオンラインに戻るまで待たなければなりません。

BitBucketやGitHubのようなもの、またはオフィスの常時オンのサーバーにプッシュすると、他の開発者は、次にオンラインになったときに、私が行った変更を簡単にプルできます。

それが私にとって中央サーバーを使用する主な理由であり、実際にはGitのせいではなく、ラップトップを使用した結果です。

于 2013-06-06T15:30:52.070 に答える
3

Gitはこの種の設定で非常にうまく機能しますが、他の誰かのチェックアウトされたブランチ（https://git.wiki.kernel.org/index.php/GitFaq#Why_won.27t_I_see_changes_in_the_remote_repo_after_.22git_push）に変更をプッシュすることは避けたいと思うでしょう。 22.3F）。コードをプッシュしたり、他の人の変更をマージしたりする統合ブランチがある場合があります。

中央リポジトリが頻繁に使用される主な理由は、中央リポジトリをすべてのコードの正規のベースと見なすことができるためだと思いますが、3つ以上ある場合は、何にマージする必要があるかを判断するのが少し難しい場合があります。開発のブランチが進行中です。

于 2011-05-10T08:26:37.240 に答える
3

初心者向けのGitをご覧ください：最も信頼のおける実用ガイド

セクション「共有チームリポジトリをどのように設定しますか？」

于 2011-05-10T08:31:25.737 に答える