2

作業したい git プロジェクトをチェックアウトしました。プッシュ許可がないので、アップストリームのメンテナーにパッチを提出します。自分のブランチを作成し、その 1 つのブランチで他の数人と共同作業したいと考えています。作業が完了したら、メイン プロジェクトの現在の責任者に対してブランチをリベースし、アップストリームのメンテナーにパッチを送信したいと考えています。問題は、1 つのブランチで作業している人々のグループ間のコラボレーションをどのように組織するかということです。

現在、次のセットアップを使用しています。

  • リポジトリのベアコピーを保持する独自の git サーバーがあります。
  • そのサーバーに作業ブランチを保存します
  • 他の開発者は自分の変更をサーバー上のそのブランチにプッシュし、他の開発者が行った変更を引き出すため、サーバーはブランチで作業するすべての人にとって中央リポジトリとして機能します。
  • master に加えられた変更は、プロジェクトの上流リポジトリから取得されます。
  • 必要に応じてマスターをサーバーにプッシュできます

これは良いセットアップだと思いましたが、アップストリームから現在のマスターに対してブランチをリベースすることにした場合、すべてが壊れることに気付きました。リベースされたブランチをローカルサーバーにプッシュすると、他の人にとっては大惨事になるので、明らかにこれは正しい設定ではありません. これについて友人と話し合ったところ、問題の原因は私自身のローカル サーバーをすべての開発者の中央サーバーとして使用していることが原因であると指摘されました。そのため、問題の原因はわかったと思いますが、git ワークフローを整理する正しい方法を思いつきませんでした。これはどのように行うべきですか？

4

1 に答える 1

1

同僚はそれぞれ、小さなイテレーションごとにマイクロ ブランチ [別名機能ブランチ] (メイン ブランチから) を作成する必要があります。これをいつでもサーバーにプッシュして、それらを表示できるようにします。各マイクロ イテレーションが完了すると、彼ら (およびあなた) はそのイテレーションをメイン ブランチの上にリベースして、それがまだ機能しており、メイン ブランチと統合する準備ができているかどうかを確認します。

ここでは、イテレーションを短く小さくして「正常に動作」し、受け入れられ、メイン ブランチにマージまたは早送りされるようにするための競争があります。場合によっては、さまざまなイテレーションが相互作用し、適切な開発者がプッシュ/プルされたマイクロ ブランチを使用して共同作業を行い、争いを避けることができます;-)

開発中に多くのクロスランニング機能がある場合は、git help workflowsマスター <- 次 <- pu (潜在的な更新) <- コントリビューター ブランチの Git メンテナーが使用するものと同様のワークフロー ( ) を使用できます。pu は後に巻き戻されます。寄稿者が巻き戻されたブランチの新鮮なビューを引き出して、彼らの変更がより大きな全体にどのように適合するかを確認するサイクルごとに。

パッチ提出

「メイン」ブランチで作業が完了したら、アップストリーム マスター (およびそれらが持っている可能性のあるリリース候補) を再度フェッチ/プルし、それらの上に変更をリベースして真に最新のものにする必要があります。

ここで、 を使用してブランチからパッチ シリーズを準備しますgit format-patch。ほとんどの場合、シリーズを紹介するカバー レターを準備します。それから、 を使用git send-emailしてそれらを送信します。ただし、それらを自分自身に送信し、上流のプロジェクトで提供されている指示を調べて、練習する価値があります。たとえば、Git の SubmittingPatches。

于 2013-01-19T11:36:38.480 に答える