githubチームのワークフロー-分岐するかどうか

私たちは現在Subversionを使用しているWeb開発者の小さなチームですが、まもなくgithubに切り替えます。

私はさまざまなタイプのgithubワークフローを検討していますが、各開発者向けのgithubのフォーク概念全体がこのような良いアイデアであるかどうかはわかりません。

フォークを使用する場合、各開発者は独自のリモートおよびローカルリポジトリを持つことになります。変更セットをプッシュするのが難しく複雑になりすぎるのではないかと心配しています。また、私の最大の懸念は、各開発者に2つのリモートを強制することです：オリジン（リモートフォーク）とアップストリーム（メインリポジトリからの変更を「同期」するために使用）。それが物事を行うためのそのような簡単な方法であるかどうかはわかりません。

これは、ここで説明されているワークフローに似ています：https : //github.com/usm-data-analysis/usm-data-analysis.github.com/wiki/Git-workflow

フォークを使用しない場合は、作業中のタスクごとにブランチを作成する中央リポジトリを使用して同じリポジトリの開発ブランチにマージすることで、おそらくうまくいくでしょう。つまり、ブランチのマージを制限することができず、中央リポジトリに多くのブランチを置くのは少し面倒かもしれません。

両方のワークフローを試したチームからの提案はありますか？

フォークの恐れは、SVNの恒星マージよりも少ないことに起因すると思います-トラブルを引き起こすのはフォークではないためです-マージです。

ダイブイン-実際に素晴らしいことがわかります！オーバーフォークする必要はありません（すべてのファイルのすべての変更に対してフォークしないでください）が、機能をフォークして、元に戻すことができます。

GitHubは、ソース管理のコア概念の多くを改善する価値のあるいくつかのバージョンと考えてください。

「安定した」ブランチと「アクティブな開発」フォークの概念は、フォークするのをためらう場合にこれらの問題の多くをカバーします。：P

私たちは両方とも、svnで非常に家にいる開発者に試してみました。そして、すでに一緒に作業してコミット権でお互いを信頼している開発者の集団であれば、gitで単一の中央リポジトリを保持し、そのリポジトリのすべてを共同作業者として追加する方が簡単でしょう。

プライベートフォークを行うこともありますが、これは通常、エキゾチックな変更や、通常は他の人が関心を持たないが、とにかくリモートで保存する1人用のテスト用です。

単一の中央レポジトリから始めて、しばらくgitで作業します。たぶん、あなたにはプライベートフォークが成長するでしょう。どちらでも構いません。

gitでは、フォークは実際には単なるブランチです。fork-for-each-developerワークフローを使用すると、各開発者が開発の変更を追跡するためのパブリック（リモート）ブランチを持つことが効果的に義務付けられます。これは、開発者間で直接（ピアツーピアで）共同作業を行うのに役立ちます。いずれの場合でも、各開発者の変更を中央レポにマージする必要があるため、これによって多くのオーバーヘッドが追加されることはないと思います。

2〜3人の開発者からなる小規模なチームの場合、レポジトリでブランチを使用して修正と機能を管理してもかまいません。問題は、それより多くの開発者がいて、開発中の機能と修正が多い場合です。

その場合、Githubのメインリポジトリには何百ものブランチがあります。いくつかは古く、忘れ去られ、統合されません。

また、誰かがレポにある共有ブランチを強制的にプッシュするコラボレーションの問題もあります。つまり、強制プッシュは履歴の書き換えであるため、そのブランチで適切に共同作業を行うことはできません。

レポジトリをフォークすると、どのブランチが進行中か、どのブランチが良いかを簡単に追跡できます。メインのリポジトリクリーナーを保持します。

ただし、テストインフラストラクチャはメインリポジトリの使用に依存している可能性があるため、ブランチをアップストリームにプッシュしない限り、フォークされたリポジトリの変更をテストすることは困難です。分岐と分岐が最適なタイミングを把握するのは難しい場合がありますが、一般的に、チームに4人以上がいて、多くの修正と機能がある場合は、分岐が最適なオプションです。