大きなプルリクエストへの対処
現在、gitワークフローを使用しているチームとプロジェクトに取り組んでいます。マスターはデプロイ可能な状態であり、ブランチは機能と修正プログラムの作成に使用されます。機能やバグ修正を完了してテストした後は、できるだけ早くそれをマスターに移します。アイデアは、ブランチをマスターに簡単にマージできるようにするために、ブランチをできるだけ小さくする必要があるということです。マスターブランチにプッシュされたコードはすべてデプロイ可能な状態にあり、テストに合格するというポリシーがあります。
開発者の1人が1つのブランチで多くの作業（数か月分）を実行し、このブランチがまだマスターにマージされていない状況にあります。現在、このブランチにはいくつかの個別の機能とたくさんのコミットがあります。基本的に、このブランチは本当に数回マージされているはずですが、今のところそうではありません。ほとんどのコードは、マスターにマージできるユニットテストで良好な状態にありますが、最新の変更は完了しておらず、テストされていないため、確かにそうではありません。
1つのブランチが他のブランチから実際に遠く離れているような状況に対処する最良の方法は何ですか？ブランチがマスターから非常に多くのコミットを奪うことを将来どのように回避できるでしょうか？
マージせずに2か月間行った開発者に修正してもらいます。たぶん、1つの大きなコードチャンクをマージして取得したり、小さなチャンクをまとめて1つずつマージしたりできます。いずれにせよ、彼らはそれを引き起こしたので、彼らは問題を修正するために脚仕事をしているべきです。
1つのブランチが他のブランチから実際に遠く離れているような状況に対処する最良の方法は何ですか？
一般に、心配する必要はありません。それは他の開発者の問題です。 2つのブランチが本当に離れすぎてマージできない場合、それらは実際には同じプロジェクトの一部ではなく、事実上のフォークを持っています。それがオープンソースプロジェクトである場合、それは問題ではないかもしれません。
この開発者が本当に優秀で、彼らのコードがチームの他のメンバーよりも優れている/賢い/重要である場合、それを彼らの問題の代わりにあなたの問題にする価値があります。そうでなければ、そうではありません。
文字通りの質問に答えるには、このような状況に対処するbest方法は、そのような状況に陥らないことです。
ブランチがマスターから非常に多くのコミットを奪うことを将来どのように回避できるでしょうか？
マージせずに何カ月も行った開発者が、彼らが引き起こした問題を修正しなければならないことに誰もが気づくようにしてください。変更の数が少ないと競合の機会が少なくなるので、マスターの方が頻繁ではなく、頻繁にマスターする方が簡単であることを全員が知っていることを確認してください。
他の人の変更を最新の状態に保つために、マスターからプルできることを人々が知っていることを確認してください。
「毎日合併すると、突然解決するのが難しい巨大な衝突が発生することはありません。」 -ライナストーバルズ
これがわかっているコミットと以前のすべてのコミットが十分にテストされていてマージする必要があるコミットがある場合は、この最後の適切なコミットからブランチアウトし、新しいブランチをマスターにマージします。
マージしたいコミットがいくつかあるが、それらは本番環境に対応していない他のコミットが散在している場合、2つの可能性があります。
- 新しいブランチを作成し、適切なコミットを選択して、masterとマージします。
- 不要なコミットを先頭にリベースしてみてください（多分、安全のために新しいブランチにあるかもしれません）。
防止方法については、「1週間以内にマスターとマージしないと、1か月間ピザを注文する」などの面白いチームルールを定義してみてください。
これが簡単な解決策です。
このユーザーが実装した機能を追跡し、機能ごとに更新されたそのブランチの各コミットに移動します。このコミットを取得し、マスターリポジトリとマージします。
これを例の形で分解してみましょう。
> Let: Branch A be the branch from the master
> Branch A+ = Branch A + new feature 1
> Branch A++ = Branch A + new feature 2
> and so on and so forth
>
> What you need to do is to go back to: Branch A+
>
> Take Branch A+ and merge it with Master.
>
> Now go to Branch A++ and merge it with (Master + Branch A+).
>
> Repeat until you've reached the final Branch A+...+ that is stable.
この方法は、最初は直感に反するように聞こえるかもしれませんが、個別の新しい機能をそれぞれ独自にマスターとマージすると、追加されたマスターブランチ "機能 "
ブランチがマスターから非常に多くのコミットを奪うことを将来どのように回避できるでしょうか？
上記の私の解決策は、あなたが採用すべき将来の方法を示していると思います。各ブランチの機能ごとまたはタスクごとの方法を使用します。
私は次のアプローチを使用することをお勧めします：
プレマスターとマスター
マスター：最終/本番レベル。あまり変更されません。常に安定していると見なされます
プリマスター：新しい機能が既存のコードに追加される領域。既存のコードベースで動作するように徹底的にテストされており、他のブランチが新しい機能の実装のために分岐できる場所です。
また、機能をバンドルし、バージョンターゲティングを目指してみてください。
バージョンターゲティング：マスターブランチのプレースホルダーとして機能する任意の番号を指定します。 「V1.0.0では、X、Y、Z機能を実現したいと考えています。V1.0.0には、次の機能もすべて用意されています。..」
マスターに対してバージョンを維持することにより、「マスター」を常に安定して本番環境に対応できるようにする方法にもなります。
最初に、@ Maciej Chalpukの提案のように、マージまたはチェリーピックできる個別のコミットが本当にあるかどうかを確認します。これが事実なら、状況はそれほど悪くなく、私は将来それについてあまり心配しないでしょう。
ただし、実際の状況では、同じコミット内で単一のブランチで複数の機能が同時に開発されている場合は、対処するのがはるかに困難になります。幸いなことに、防止方法が組み込まれています。各機能の変更を別々のブランチに分離し、それらをマージする前にリクエストをプルする必要があります。両方のアトミックマージを取得し、この開発者がそれを実行しないようにします。未来。
機能を分離する実際のプロセスは完全に手動です。 masterから新しいブランチを作成し、それに関連するmegaブランチからの変更をコピーします。機能をコンパイル、テストし、pullリクエストをプッシュして発行します。コードの変更が混ざり合わないほど、実行が容易になります。彼がそれらすべてに対して単一の方法をハッキングしているなら、まあ、楽しんでください。彼は二度とそれをしません。
大きなプルリクエストの問題を修正することは1つのことであり、それに関していくつかの良い答えがあります。しかし、古くなったブランチを扱う場合は、チームの作業を扱うためにプロセスを再検討する必要があるかもしれません。
アジャイルまたはSCRUMフレームワーク内で作業している場合、チームは本当に機能が完了しておらず、反復/スプリントの一部としてマージされなかった理由を尋ねているはずです。反復内に収まらないほど大きすぎる場合は、より小さなチャンクに分割されているはずです。
また、コードの所有権の問題も提起されます-チーム内で、個々の開発者が自分の作業を個別に所有しますか、それともチーム全体が協力してアイテムが確実に完了するようにしますか？
もちろん、上記はあなたのチームが何らかの会社構造の中にいることを前提としています。これがボランティアの貢献者によるオープンソースプロジェクトである場合、それはまた別の話です。一般に、そのようなプロジェクトはワークフローに対する制御が緩くなっていますが、受け入れ可能なプルリクエストを生成する責任は、個々のコントリビューターにかかる頻度が高くなります。
多くの点で、これはプロセスの問題になります。おそらく、必要なプロセスには、長期間実行されるマージされていないブランチを定期的に（毎週？毎月？）チェックすることが含まれます。一部のツールは、これを視覚的にチェックするのを簡単にします。例えばgithubの「ブランチ」リンクにアクセスすると、各ブランチの前後の距離が表示されます。