現在のブランチの先端がリモートブランチより遅れているため、更新が拒否されました。質問する

私たちのワークフローは次のようになります。 というブランチがありdev、 からアクセスできますorigin/dev。変更を行うときは、 からブランチを作成します。

git checkout -b FixForBug origin/dev

現在、追跡中の というブランチがありますFixForBug(これが正しい言葉だと思います) origin/dev。したがって、 を実行すると、そこgit pullから新しい変更が取り込まれるのでorigin/dev便利です。修正が完了したら、同じ というリモート ブランチにプッシュします。

まず、変更をすべてプルダウンしてorigin/devリベースを実行します。

git pull --rebase

次に、変更を同じ名前のリモート ブランチにプッシュします。

git push origin FixForBug

これで、リモート サーバーにブランチが作成され、その変更を承認して開発ブランチにマージするためのプル リクエストを作成できます。自分自身に何かをプッシュすることorigin/devはありません。これはかなり一般的なワークフローだと思います。

初めて を実行するとgit push、正常に動作し、リモート ブランチが作成されます。ただし、2 回目にプッシュすると(コード レビュー中に誰かが問題を指摘した場合など)、次のエラーが発生します。

エラー: 'https://github.mydomain.info/Product/product.git' への参照の一部のプッシュに失敗しました。
ヒント: 現在のブランチの先端がリモートの対応するブランチより遅れているため、更新が拒否されました。再度プッシュする前に、リモートの変更を統合してください (例: ヒント: 'git pull ...')。
詳細については、'git push --help' の「fast-forward に関する注意」を参照してください。

しかし、 を実行すると、コミットが 1 つgit status進んでいるorigin/dev(当然のことですが) と表示され、ヒントに従って を実行するとgit pull、すべてが最新であると表示されます。これは、アップストリーム ブランチとは異なるブランチにプッシュしているためだと思います。次を実行して、この問題を修正できます。

git push -f origin FixForBug

その場合、 (強制更新)と表示され、変更がリモート ブランチにプッシュされ、リモート ブランチではすべてが正常に行われているように見えます。

私の質問:

このシナリオではなぜ が-f必要なのでしょうか? 通常、何かを強制する場合は、間違ったことをしているか、少なくとも標準的な方法に反しているためです。 これを実行しても問題ありませんか、それともリモート ブランチで何かが台無しになったり、最終的に私のものを dev にマージする必要がある人に面倒なことを引き起こしたりするでしょうか?