現在、3人の開発者が機能ブランチに取り組んでいます。WIPコミットをfeature_branch（およびorigin / feature_branch）にコミットしてプッシュし続け、1日おきにマスターをfeature_branchにマージして、発生している他のすべての変更を最新の状態に保つようにしました。
feature_branchには、1つまたは2つのコミットに簡単に押しつぶすことができる最大100のコミット（多数のマージコミットを含む）が含まれるようになりました。これまで、機能ブランチで作業が行われると、それをマスターにマージするだけで、スパゲッティログとチェックポイントコミットがマスターにプッシュされていました。
代わりに、リベースしたいと思います。feature_branchでの作業が完了し、開発者がこのブランチとの間で新しいコミットをプルまたはプッシュすることはなく、変更をマスターにマージするときが来た場合、リベースはリベースの黄金律に違反しますか？
主題を読んだ後、マスターの上にインタラクティブをリベースするのは良い考えのように聞こえます（そして、ffマージになるマスターにマージし直します）が、私は何かを見逃していないことを確認したいだけです。
また、（更新を維持するために）マスターをマージし続けた後のfeature_branchのリベースに何か問題がありますか？マージコミットを潰しても大丈夫ですか？
ありがとう！
リベースとマージのどちらを選択するかは、ある程度好みの問題です。あなたが持っているリンク（公開されたコミットのリベースを避けるための「リベースの黄金律」を含む）は、カジュアルユーザーにとって物事をシンプルに保つ上品なルールを使用しています。ただし、あなたとあなたの同僚全員がそれらに対処する方法を知っている限り、あなたとあなたの同僚が公開されたコミットのリベースを許可することに事前に同意できないということは何もありません。
gitのgitリポジトリには、意図的にリベースされたいくつかのブランチがあり、nextand pu（Skunk-odorpuではなくPick Upを表します:-)）と呼ばれます。いつgit fetch、最新のgit、あなたは多くの場合、このようなものが表示されます。
+ 104e649...1352ede next -> origin/next (forced update)
+ cf10e94...a619c8c pu -> origin/pu (forced update)
なお、forced updateこれは、git fetch更新がない早送りであり、唯一の理由のために発生しますので、印刷物+にrefspecフェッチ。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加