マスターブランチでフィーチャーブランチを最新の状態に維持しようとすると、マスターブランチを自分のフィーチャーブランチに時々マージする必要があります。マスターブランチからフィーチャーブランチにマージし、自分のフィーチャーブランチで自分の仕事をコミットする方法を教えてください。
このようなマージが成功すると、機能ブランチに新しいコミットが作成されるのは間違いですか？
このようなマージが失敗した場合は、手動でマージ競合を解決する必要があります。そのような場合には、私が競合
また、マージの競合を解消し、機能ブランチの作業を異なるコミットに変更するために、私は別の変更を加える必要がありますか？ 私は
一般的に、マスターブランチから自分のフィーチャーブランチにマージし、自分のフィーチャーブランチで自分の仕事をコミットする方法を教えてください。
masterからフィーチャーブランチへのマージは、通常はがマージのための新しいコミットを生成することは事実です。このルールの例外を考案できますが、フィーチャーブランチにまだコミットがない場合に限ります。 を確実ににコミットするようにしたい場合は、no-ffオプションでマージできます。
私の助言は、できるだけ少ない変更をにマージコミットすることです。関連する理由がいくつかあります。
まず、マージは2つの作業ラインのコンフルエンスを表すと考えられます。マージコミットメッセージは、通常、「マージされたマスターをsome_featureにする」のようなものです。追加の作業をすると、関係のないことを示すコミットメッセージが必要になります。後で誰かがあなたの変更を後で探しているときに、そのようなメッセージが失われる可能性があります。
そのため、マージコミットのデフォルトのログ出力にはパッチは含まれていません。あなたは1つを得ることができますが、これは3つ（またはそれ以上）のパッチで、多くはです。したがって、変更内容を簡単に調べたい場合は、マージする必要はありません。
次のページ：どのような変更がバグを導入したのか気になるかもしれません。一般に、あまりにも複雑なコミットをすると、あまりにも多くのことをすると、これを絞り込むのに役立つツールの有効性が低下します（bisectなど）。そして、「マスターからのマージは私のフィーチャーブランチを壊しました」は、「自分のフィーチャーに追加した最新の仕事が自分のフィーチャーブランチを破った」というのとはまったく異なる決まりでしょう。
gitの種類では、マージが単なるマージであると仮定している状況もあります。私は主にリベース操作を考えています。このようなマージによってリベースすることはめったにないかもしれません。しかし、そうした場合、マージに無関係な変更が含まれていると、不必要な問題が発生します。
手動で「再実行」する必要があることもあります。マージで関連のない作業を追加した場合は、これもまた難しくなります。