私たちのチームは git サブモジュールを使用していますが、プルでいくつかのエラーが発生しました。これは、最近更新したにもかかわらず遅れていることを示しています (それ以来、リモート コミット/プッシュはありません)。これは、次の 2 つのシナリオで発生します。
HEADサブモジュールで切り離されている、または- 使用時
git commit --amend。
これらのことが起こったシナリオを示してみます。私の質問は、特定のエラーがどこにあるのか、そしてそれらを修正するための簡単な方法（私たちの汚いハックよりも優れている）を知っている人はいますか?
シナリオ 1 - 切り離されたHEAD
- 次のいずれかを発行します。
git clone --recursive $REPO $DIRgit sfe 'git pull origin master'git submodule update --recursiveHEAD- 孤立した状態になりがちなので、実際にはあまり使用していません
masterを使用して、すべてのブランチがオンになっている(または少なくとも切り離されたHEAD状態ではない)かどうかを確認しますgit sfe 'git branch'。そうでない場合は、 を発行しgit sfe 'git checkout master'ます。(現在、マージの必要性を最小限に抑え、起動して実行するために、全員 (〜4 人) が master で開発しています)- detached
HEADにいる場合は、変更を加えてから (ステージングされていないファイルが作業ディレクトリにとどまるように) に切り替え、masterそれらの変更をステージングしてコミットし、プッシュを試みます。Git は、遅れているためプルする必要があると言います。これは次の方法で修正できます。- 「ねじ込み」と言って、完全にクリーンなスーパーモジュールをチェックアウトし、 detached
HEADにいないことを確認し、そこから作業します - リビジョン番号を取得し
git checkout master、次に a を発行して、git merge $REV現在の変更を再マージするという苦痛を経験し、そこにあると思われる過去の変更と競合します。
- 「ねじ込み」と言って、完全にクリーンなスーパーモジュールをチェックアウトし、 detached
シナリオ 2 - コミットの修正
- これにはあまりありません。私は自分で開発し、 を発行し
git commit --amend、それらの変更をプッシュしようとします。ただし、これを行うと、遅れているためマージする必要があることがわかります。私がそうすると、現在のすべての変更を過去のリビジョンと再マージするという苦痛なプロセスが再び発生します。- これは、もはやコミットではないコミットに基づいたものをプッシュしようとしているため
HEADですか?
- これは、もはやコミットではないコミットに基づいたものをプッシュしようとしているため
注:git sfeのエイリアスですgit submodule foreach --recursive(マゾヒズムのためだけに、ネストされたサブモジュールがいくつかあります [というか、コードを分離できるようにする必要があり、サブサブモジュールの配置が理にかなっています])