大規模な分散チームが Git を使用している様子についてのビデオを見たり見たりしましたが、分散していないチームの他のメンバーと一緒にオフィスで働いている私たちについてはどうでしょうか? リポジトリとワークフローをどのように構築する必要がありますか?
Subversion や CVS を単一の権限ポイントとして使用している従来のオフィスについて考えてみてください。確かに、これらのチームはそれぞれ独自の Git リポジトリを維持し、必要に応じて相互にプッシュ/プルすることができますが、これは多くの状況ですぐに悪夢に変わります。または、それぞれが独自のリポジトリを維持し、チームの「マスター」と呼ばれる単一のリポジトリと同期することもできます。または、DVCS によって可能性が開かれるワークフローの任意の組み合わせが存在する可能性があります。
あなたのチームはどのように機能しますか? 便利なワークフローは何ですか?
Yahoo! のやり方が好きです。ユーザー インターフェイス (YUI) チームが機能しているようです。私は Yahoo に所属していませんし、そのチームにも所属していませんが、彼らの git commit ログは彼らのプロセスについて多くのことを明らかにしています。
YUI チームは、チームの全員がコミット アクセスできる中央リポジトリを維持しています。このリポジトリへのコミット後、定期的に (すべてのプッシュの後かもしれませんが、そうは思いません)、ビルド システムが起動し、YUI を再構築して、新しくタグ付けされたコミットを github にプッシュします。そこでコミュニティはコードをフォークして作業することができます。 .
私は、プロジェクトの「公式」ステータスを表す中央リポジトリに賛成です。確かに、同僚とコードを共有したい場合は、彼らが私からブランチをプルするように手配することができ、その方法で共同作業を行うことができます。
「マスター」リポジトリには、単体テストを開始してシステムを構築するために「マスター」リポジトリでプッシュ/プルトリガーを構成できるため、継続的な統合が容易になるなど、他の利点もあります。また、リポジトリの最新の「既知の良好な」バージョンがどこにあるかを全員が確実に把握できるようにするため、プロジェクトをビルド、公開、またはテストする必要がある場合、「マスター」リポジトリがその準備ができているという合理的な保証が得られます。 .
Git は考えられるほぼすべてのワークフローをサポートしますが、小規模なチームであっても、「公式」リポジトリがどこにあるかについて質問されることは望ましくありません。特にリリースが近づくと、メンテナンスの悪夢につながる可能性があり、不快です。
素敵なブログhttp://nvie.com/git-modelとコメントをご覧ください
github チームが使用するワークフローを見てみましょう。
http://scottchacon.com/2011/08/31/github-flow.html
github を使用する必要がありますが、非常に簡単でクリーンです。