これは単純な git シナリオだと思っていましたが、何が足りないのでしょうか?
masterブランチとブランチがありますfeature。 で作業を行いmaster、 で作業を行いfeature、さらに で作業を行いますmaster。最終的には次のようになります (辞書順はコミットの順序を意味します)。
A--B--C------F--G (master)
\
D--E (feature)
git push origin masterリモートをmaster最新の状態に保つのも、git push origin feature( がオンのときにfeature) 作業用のリモート バックアップを維持するのも、問題はありませんfeature。これまでのところ、問題ありません。
しかし、今度はマスターのコミットfeatureの上にリベースしたいので、と を実行します。まだ大丈夫です。これで次のようになります。F--Ggit checkout featuregit rebase master
A--B--C------F--G (master)
\
D'--E' (feature)
問題:featureでリベースされた新しいブランチをバックアップしたいと思った瞬間git push origin feature、リベースによりツリーが変更されたため、プッシュが拒否されますgit push --force origin feature。 これは でのみ解決できます。
--force必要かどうかわからないまま使うのは嫌です。では、本当に必要なのでしょうか? リベースすると、次は必ずpushフルになるのでしょうか--force?
この機能ブランチは他の開発者と共有されていないため、強制プッシュしても事実上問題はなく、データが失われることもありません。質問はより概念的なものです。
ベストアンサー1
問題は、git pushリモート ブランチをローカル ブランチに高速転送できることを前提としていることです。つまり、ローカル ブランチとリモート ブランチの違いは、ローカルでは最後に次のような新しいコミットがいくつかあることだけです。
Z--X--R <- origin/some-branch (can be fast-forwarded to Y commit)
\
T--Y <- some-branch
コミットを実行すると、git rebaseD と E が新しいベースに適用され、新しいコミットが作成されます。つまり、リベース後は次のような状態になります。
A--B--C------F--G--D'--E' <- feature-branch
\
D--E <- origin/feature-branch
このような状況では、リモート ブランチをローカルに早送りすることはできません。ただし、理論的にはローカル ブランチをリモートにマージできます (明らかにその場合は必要ありません)。ただし、git push早送りマージのみを実行すると、エラーが発生します。
そして、--forceオプションが行うことは、リモート ブランチの状態を無視し、プッシュするコミットに設定することです。つまり、git push --force origin feature-branch単にorigin/feature-branchlocal で上書きするだけですfeature-branch。
master私の意見では、そのブランチで作業しているのが自分だけである限り、機能ブランチをリベースしてリモート リポジトリに強制的にプッシュすることは問題ありません。