git merge の代わりに git rebase を使用するのはいつですか? .
ただし、この場合にどのソリューションを選択するかを確認したいと思います。
新しい機能を実装したいmasterので、新しい機能ブランチに分岐します。
私は Feature で 10 件のコミットを行い、他の誰かが Master で他のコミットを行っています。
私の質問は、テスト目的でブランチをマスターから離したいのですが、新しいマスターコミットを統合してテストする必要があるかどうかです。したがって、マスターをフィーチャーにマージする必要があります (テスト前にマスターに変更を適用するフィーチャーをマスターにマージするのではなく)、または実行する必要がありrebaseますか?
私がよく知っているワークフローには、トランク、統合ブランチ、機能ブランチがあります。
私は「派生」ブランチに向かってリベースしています。(派生ブランチとは、トランクから離れた方向を意味します)、統合ブランチに向かってマージします。
統合先のブランチと同じ歴史を持つブランチで常に作業していることを気に入っています。マージが早送りになるのが好きなので、マージしたばかりのものがブランチでテストしたものとまったく同じであることを知っています。
2 人の開発者が同じリポジトリにコミットする場合 (競合が発生します)、マージ コミットを作成して 2 つのコミットをマージするか、コミットの 1 つ (自分の) を他のコミットの上にリベースできます。マージコミットを生成する代わりに、リベースする方が常に良いです。