大規模なプルリクエストの処理

現在、gitワークフローを使用しているチームとプロジェクトに取り組んでいます。マスターはデプロイ可能な状態であり、機能とホットフィックスを作成するためにブランチが使用される必要があります。機能またはバグ修正が完了してテストされたら、できるだけ早くマスターに移行します。アイデアは、ブランチをできるだけ小さくして、それらをマスターにマージしやすくすることです。masterブランチにプッシュされたコードはデプロイ可能な状態にして、テストに合格するというポリシーがあります。

開発者の1人が1つのブランチで多くの作業（数か月分）を行っており、このブランチがまだマスターにマージされていない状況があります。現在、このブランチにはいくつかの別個の機能と多数のコミットがあります。本質的に、このブランチは実際には数回ですでにマージされているはずですが、今のところそうではありません。ほとんどのコードは、マスターに戻すことができる単体テストで良好な状態にありますが、最新の変更は、完了しておらずテストされていないため、確かにそうではありません。

あるブランチが他のブランチから本当に遠く離れているような状況に対処する最良の方法は何ですか？将来、ブランチがマスターから非常に多くのコミットを取得するのを避ける方法はありますか？

マージせずに2か月間行った開発者に修正してもらいます。たぶん、1つの大きなコードチャンクをマージして、1つずつマージする小さなチャンクの束を取得できます。いずれにせよ、彼らは問題を引き起こしたので、彼らは問題を解決するためにレッグワークを行うべきです。

あるブランチが他のブランチから本当に遠く離れているような状況に対処する最良の方法は何ですか？

一般的には、心配する必要はありません。それは他の開発者の問題です。二つの分岐がある場合は、本当に離れすぎてマージするには、その後、彼らはもう本当に同じプロジェクトの一部ではなく、あなたは事実上のフォークを持っています。それがオープンソースプロジェクトである場合、それは問題ではないかもしれません。

この開発者が本当に優秀であり、彼らのコードが他のチームの組み合わせよりも優れている/スマートである/重要である場合は、彼らのコードではなくあなたの問題にする価値があります。そうでなければ、そうではありません。

文字通りの質問に答えるために：この種の状況に対処する最善の方法は、そのような状況に陥らないことです。

将来、ブランチがマスターから非常に多くのコミットを取得するのを避ける方法はありますか？

マージせずに数か月間行った開発者が、彼らが引き起こした問題を修正しなければならないことに誰もが気づくようにしてください。変更が少ないほど衝突の機会が少ないことを意味するため、頻繁にマスターすることは頻繁ではないことを全員が知っていることを確認してください。

他の人の変更を最新の状態に保つために、マスターからプルできることを人々が知っていることを確認してください。

「毎日合併すれば、突然解決するのが難しい巨大な紛争に突入することは決してありません。」-ライナス・トーバルズ

その引用は、彼がグーグルで行った講演からのものであり、ここにトランスクリプトがあり、ここにビデオがある。

これを知っているコミットがあり、以前のすべてのコミットが十分にテストされており、マージする必要がある場合は、この最後の正常なコミットからブランチアウトし、新しいブランチをマスターにマージします。

マージしたいコミットがいくつかあるが、それらが本番用ではない他のコミットに散在している場合、2つの可能性があります：

1. 新しいブランチを作成し、適切なコミットを選択して、マスターとマージします。
2. 不要なコミットを最上部にリベースしてみてください（おそらく安全のために新しいブランチで）。

防止方法については、「1週間以内にマスターとマージしないものは1か月間ピザを注文します」などの面白いチームルールを定義してみてください。

まず、@ Maciej Chalpukによる提案のように、マージまたはチェリーピッキングできる個別のコミットがあるかどうかを確認します。この場合、状況はそれほど悪くなく、将来的にはあまり心配しません。

ただし、実際の状況として、同じコミット内で単一のブランチで複数の機能が同時に開発された場合、対処するのは非常に大きな苦痛になります。幸いなことに、防止方法が組み込まれています。各機能の変更を別々のブランチに分け、それらをマージする前にリクエストをプルすることを開発者に要求します。未来。

機能を分離する実際のプロセスは完全に手動です。マスターから新しいブランチを作成し、それに関連するメガブランチからの変更をコピーします。コンパイル、機能のテスト、プッシュリクエスト、プルリクエストの発行。コードの変更が混ざり合わないほど、簡単になります。彼がそれらのすべてのために単一の方法をハッキングしていたなら、まあ、楽しんでください。彼は二度とそれをしません。

これが簡単な解決策です。

この人が実装した機能を追跡し、機能ごとに更新されたそのブランチの各コミットに移動します。このコミットを取得して、マスターリポジトリとマージします。

これを例の形式で分解してみましょう。

Let：Branch AをマスターからのブランチにしますBranch A + = Branch A + new feature 1 Branch A ++ = Branch A + new feature 2などなど

必要なことは、ブランチA +に戻ることです。

ブランチA +を取得し、マスターとマージします。

次に、ブランチA ++に移動し、（マスター+ブランチA +）とマージします。

安定した最終ブランチA + ... +に到達するまで繰り返します。

この方法は、最初は直感に反するように聞こえるかもしれませんが、それぞれの新しい機能をそれ自体でマスターにマージすると、「追加された機能ごと」のマスターブランチを簡単に切り替えることができます。

将来、ブランチがマスターから非常に多くのコミットを取得するのを避ける方法はありますか？

上記の私のソリューションは、あなたが採用すべき将来の方法を示していると思います。各ブランチの機能ごとまたはタスクごとの方法を使用します。

次のアプローチを使用することをお勧めします。

プリマスターとマスター

マスター：最終/生産レベル。あまり変更されません。常に安定しているとみなされる

プリマスター：既存のコードに新しい機能が追加される領域。既存のコードベースで動作するように徹底的にテストされており、他のブランチが新しい機能の実装を分岐できる場所です。

また、機能をバンドルして、バージョンターゲットを目指してみてください。

バージョンターゲット：マスターブランチのプレースホルダーとして機能する任意の番号を指定します。「V1.0.0では、X、Y、Zの機能を実現したいと考えています。V1.0.0では、これらすべての機能も利用できます。...」

マスターに対してバージョンを維持することにより、「マスター」を常に安定させ、いつでも本番環境で使用できるようにすることもできます。

大規模なプルリクエストの問題を修正することは1つのことであり、それに関するいくつかの良い答えがあります。しかし、古くなったブランチを扱う場合は、チームワークを扱うためのプロセスを再検討する必要があります。

アジャイルまたはSCRUMフレームワーク内で作業している場合、チームは、機能が反復/スプリントの一部として完了およびマージされなかった理由を実際に尋ねる必要があります。イテレーション内に収まるには「大きすぎる」場合は、小さなチャンクに分割する必要がありました。

また、コードの所有権の問題も発生します-チーム内で、個々の開発者が独自の作業を個別に所有しているのですか、それとも完全なチームが協力してアイテムを完成させるのですか？

もちろん、上記では、チームが何らかの企業構造内にあることを前提としています。これがボランティアの貢献者によるオープンソースプロジェクトである場合、それは別の話です。一般に、そのようなプロジェクトではワークフローをより緩やかに制御できますが、受け入れ可能なプルリクエストを生成する責任は、個々の貢献者により多く生じます。

多くの点で、これはプロセスの問題になります。おそらく、必要なプロセスには、実行時間の長いマージされていないブランチの定期的なチェック（毎週？毎月？）が含まれます。一部のツールでは、これを視覚的に簡単に確認できます。たとえば、GitHubで「ブランチ」リンクにアクセスすると、各ブランチがどれだけ先/後ろにあるかが示されます。