git - 大規模なチームで DVCS はどのように使用されますか?

Question

私は最近、個人的なプロジェクトで Git を使い始めました。DVCS が職場でどのように役立つかがわかります (大規模なエンタープライズソフトウェア会社で、現在 Perforce を実行しています)。たとえば、私のチームでの機能作業は、ほとんどが独自のブランチを作成する開発者で構成されています。時々、これらは開発者の小さなチーム間で共有されます。この場合、DVCS を使用する方が効率的だと思います。

ただし、より一般的なケースとして、中規模から大規模のチームで DVCS を使用している人々の意見を聞きたいと思います。

N-way マージをどのように処理しますか? これは一般的なシナリオですか？Mercurial は、(N-1) 2 方向マージを実行することによる N 方向マージのみをサポートします (これが他の DVCS で推奨されるソリューションであることがわかります)。
信頼できる単一の中央リポジトリを使用していますか、それとも本当に P2P ですか?
開発者は頻繁にコードを相互にプッシュおよびプルしますか? それとも、すべてが中央リポジトリを経由しますか?

score 13 · Accepted Answer

以前の雇用主の私のチームはGitを使用していましたが、それは私たちにとってうまく機能しました。私たちはそれほど大きくはありませんでしたが（おそらく16かそこら、8人の本当にアクティブなコミッターがいますか？）、私はあなたの質問に対する答えを持っています：

N-Wayマージはそれほど一般的ではありません。「リリースエンジニアリング」プロセスを容易にするスクリプトを記述できるようにするブランチの命名に関するいくつかの規則を考え出しました（リリースエンジニアがいなかったので、私は怖い引用符を使用します）。 3つ以上のブランチのマージで問題が発生しました（次のブランチを参照）。
（および＃3）。3つの理由から、開発サーバーに中央リポジトリがありました。（a）開発マシンにはRAID5（フォールトトレラント性が高い）と夜間バックアップ（開発ワークステーションは夜間ではなかった）があり、（b）本番リリースは開発サーバー上に構築されました。（c）中央リポジトリの簡略化されたスクリプトを使用する。その結果、N-wayマージはまったく発生しませんでした。N-wayに最も近いのは、誰かが横方向に合流してから縦方向に合流したときでした。

Gitは、柔軟性が高いため、私たちにとって本当に素晴らしいものでした。ただし、いくつかの規則（ブランチ名とタグ名、リポジトリの場所、スクリプトなど、プロセス）を確立する必要がありました。そうしないと、少し混乱した可能性があります。コンベンションを設定すると、柔軟性は素晴らしかったです。

更新：私たちの慣習は基本的に次のとおりでした：

すべての中央リポジトリを収容したNFSサーバー上のディレクトリ
コンポーネントを共有するプロジェクトがいくつかあったので、基本的には独自のリポジトリを備えたライブラリに分割し、成果物のプロジェクトにはそれらをgitサブモジュールとして含めました。
上からバージョン文字列とリリース名が課されていたので、それらのバリエーションをブランチ名として使用しました
同様に、タグについては、プロセスで指定されたリリース名に従いました。
成果物のプロジェクトには、シェルスクリプトに読み込んだプロパティファイルが含まれていました。これにより、すべてのプロジェクトのリリースプロセスを管理する単一のスクリプトを作成できました。ただし、各プロジェクトにはプロセスにわずかなバリエーションがありました。バリエーションは考慮されていました。それらのプロパティファイルで
任意のタグから成果物パッケージを再構築するスクリプトを作成しました
gitを使用すると、PAMや通常のユーザー権限（sshなど）を使用してアクセスを制御できます
マージがいつ行われるべきかなど、箇条書きに入れるのが難しい他の規則がありました。本当に、私と他の人は一種の社内の「git gurus」であり、ブランチの使用方法とマージのタイミングを全員が理解できるように支援しました。
マスターブランチにdiff-bombをドロップせずに、小さなチャンクでコミットするようにするのは困難でした。1人の男が約2週間の作業を1つのコミットに落とし、最終的にすべてを解明する必要がありました。膨大な時間の無駄であり、すべての人にとって苛立たしいことです。
コミットに伴う有益で詳細なコメント

チームが経験を積み、お互いに協力することを学ぶにつれて、他にも学ぶことがありましたが、これで私たちを始めることができました。

更新：これまでにそのようなことをフォローしている人は誰でもそれについてすでに知っていますが、Vincent Dreissenは、Gitを使用した分岐およびリリースエンジニアリングに関する堅実でかなり包括的な（しかし誇張ではない）テイクを書いています。次の2つの理由から、彼のプロセスを出発点として使用することを強くお勧めします。

多くのチームがこの方法でそれを行っているか、いくつかの類似したバリアント（Linux、Git、および他の多くのOSSプロジェクトチームを含む）を使用しています。これは、この方法がテストされ、ほとんどの状況で成功するように調整されていることを意味します。このモデルの制約内で直面および解決されていない問題に直面する可能性はほとんどありません。
前述の理由により、Gitの経験を持つほとんどのエンジニアは、何が起こっているのかを理解できます。リリースプロセスの基本的な性質に関する詳細なドキュメントを作成する必要はありません。プロジェクトまたはチームにのみ固有のものを文書化するだけで済みます。

score 7 · Accepted Answer

whygitisbetterthanxのワークフロースキーマ：

_{（出典：whygitisbetterthanx.com）}

これをさらに多くの開発者にスケールアップするには、統合マネージャーと開発者の間に「信頼できる中尉」の別のレイヤーを追加するだけです。

score 5 · Accepted Answer

Darcsを使用して、 Glasgow Haskell Compilerチームで数年間働いています。私は最近（数か月）、パフォーマンスと教育の向上の両方のために、レポの自分のコピーにgitを使い始めました。

N-way マージをどのように処理しますか?

N-way マージはありません。各開発者はパッチのストリームを作成し、ストリームは各リポジトリで一度に 1 つずつマージされます。したがって、N 人の開発者が同時に変更を加えると、ペアごとにマージされます。
単一の中央権限のあるリポジトリを使用していますか?

絶対。何が GHC で何がそうでないかを判断する唯一の方法です。
開発者は頻繁にコードを相互にプッシュおよびプルしますか? それとも、すべてが中央リポジトリを経由しますか?

開発者と使用している VCS に依存すると思います。GHC プロジェクトでは、ほとんどすべてのプルとプッシュが中央リポジトリを通過します。しかし、中央レポへのプッシュには重量級の (自己管理型) ゲートキーパーがいて、同僚が今すぐ必要なバグ修正を持っている場合、私は彼または彼女のレポから直接プルします。darcs を使用すると、(git のように状態全体を取得するのではなく) 1 つのパッチだけをプルするのは非常に簡単です。また、darcs の経験が豊富な開発者仲間が、この機能を私よりもはるかに多く使用していることを私は知っています---そして彼らはそれがとても好きです。

ではgit、他の 1 人の開発者と密接に作業しているとき、他の 1 人と共有するためだけに新しいブランチを頻繁に作成します。そのブランチが中央レポにヒットすることはありません。

score 2 · Accepted Answer

かなり有名な "Tech Talk: Linus Torvalds on git" では、Linux での使用方法が説明されています (私が考えることができるチームと同じくらいの大きさです)。

私の記憶が正しければ、その使用は軍の指揮命令系統に例えられました。各モジュールには、開発者からのプルリクエストを処理するメンテナーがいて、モジュールメンテナーから公式の kernel.org git リポジトリ。

「Linux: Managing the Kernel Source With 'git'」でも説明されていますが、これも簡潔な説明とは言えません..

score 1 · Accepted Answer

Linuxカーネル開発者がどのように機能するかを調べるのがおそらく最善です。彼らは非常に複雑なワークフローを持っており、変更は多くのソースから送信され、各サブシステムの信頼できる開発者（中尉と呼ばれます）が変更をプルし、満足のいくときにLinusに送信します。Linusは最終的にそれらをツリーにプルするか、それらを拒否します。もちろん、それよりも複雑ですが、それは一般的な概要です。

score 1 · Accepted Answer

これが一例です（決して「普遍的な」ものではありません）

中央の VCS (さまざまなプロジェクトに応じて ClearCase または SubVersion) があり、それらを「公式」開発作業 (開発、パッチ、修正) に使用しています。ここでは、ブランチの数が制限され、十分に識別されています。

ただし、多くの中間状態を含むリファクタリング開発では、何も機能せず、多くの開発者が独自のアクティビティベースのブランチまたはブランチを持つ必要があるため、P2P 方式でそれらの開発者間でいくつかの Git リポジトリがセットアップされます。
作業が何らかの 0.1 の安定性を達成し、マージが削減されると、その作業は VCS に再インポートされ、「整然とした」中心的な方法で作業を進めることができます。

Windows 上の Git (MSysGit) はうまく機能するので、小さな初期開発をその方法で迅速に行うことができます。

ただし、本格的なプロジェクト開発のために Git をまだ評価しています。

git - 大規模なチームで DVCS はどのように使用されますか?

6 に答える 6

Related

Reference