問題タブ [fast-forward]

次のことを行うコミット (またはコミットのセット) を git pull しようとすると、Git はマージを中止します。

1. サブディレクトリにあるサブモジュールを削除します
2. サブディレクトリにサブモジュールの内容を追加します (異なるファイル、同じファイル名)

これをアクションごとに個別の git pull に分割すると、マージの競合は発生しません。ただし、これには問題があります。他のユーザーが 2 番目のコミットを git pull するまでプロジェクトをコンパイルできないためです。誰かが最初のコミットをプルしていない限り、2 番目のコミットをプッシュすることはできません。

Git でこのような変更を早送りする方法はありますか?

アップデート：

これは私のリポジトリ構造です:

これらは、ローカル リポジトリから実行するコマンドです。

現在、これは別のローカル リポジトリ (同僚のリポジトリなど) の状態です。

そして今、同僚は両方のコミットを git pull しようとしています:

「2 つの個別の git プル」とは、同僚がサブモジュールを削除する最初のコミットをプルしたときのことです。これにより問題は発生しません。その後、2 番目のコミットをプッシュします。これにより、ファイルがメイン リポジトリに追加されます。最後に、2 番目のコミットをプルします。繰り返しますが、問題はありません。

上記の段落で説明したように、これが「2 つの git pull で」機能し、1 つの git pull では機能しないのはなぜですか?

これを 1 つの git pull で機能させるためにできることはありますか?

私は昨夜自動操縦をしていて、無意識のうちに大きな機能feature/bigfeatureブランチを私たちのdevelopブランチにマージし、リモートにプッシュしましたorigin/develop. 私は開発が完全に無傷で変更されていないことを望んでいました。

このフィーチャー ブランチは数週間にわたって開発中であり、ワークフローの一部は継続的に origin/develop をそれにマージしていました。これにより、マージ/プッシュを元に戻すことが難しくなります (不可能ですか?)

各ブランチには時間の経過とともにいくつかのコミットがあり、これを解く方法は履歴を見ると明確ではありません。マージコミットの復帰を試みました：

git revert 94c8d1f0 -m 1 しかし、これは、origin/develop のフィーチャー ブランチへの最後のマージ後に、狭い範囲のコミットを元に戻すだけです。reflog でマージを特定しました。

だから私はできることを知っていますgit reset --keep develop@{N}が、繰り返しますが、bigfeature に関係のない他の多くのオリジン/開発へのマージを失っているようです。戦略は、時間をさかのぼってチェリーピックを始めることだと思います。しかし、別の方法はありますか？

What is the difference between a fast-forwarded git merge and a git rebase? Don't both accomplish keeping history linear and no merge commits? If so, why would one use one over the other? If not, which is what I think is true, what is the whole story that I'm not seeing?

Thanks!