質問

いくつかのサブモジュールを参照する git スーパープロジェクトがあり、残りのプロジェクト メンバーがその中で作業できるようにワークフローをロックダウンしようとしています。

この質問では、私のスーパープロジェクトが次の名前であるとします。 supery そしてサブモジュールは呼び出されます subby. 。(これは私がやろうとしていることの簡略化です...実際にはバージョンのブランチを使用していませんが、質問としてレイアウトするのが最も簡単だと思いました。)

私のマスターブランチ supery タグが付いています v1.0 git プロジェクトの subby サブモジュールとして参照されます。の支店 supery 呼ばれた one.one サブモジュールの参照をタグを指すように変更しました v1.1subby.

これらの各ブランチ内では問題なく作業できますが、 one.one からの変更を含むブランチ master ブランチ いくつかの競合が発生しましたが、解決方法がわかりません。

基本的に、実行した後、 git pull . master 中にいる間 subby ブランチを開くと、追加のサブモジュールが作成されるようです。

プル/マージの前に、次から目的の応答を受け取ります。 git submodule から one.one 支店:

$ git checkout master
$ git submodule
qw3rty...321e subby (v1.0)
$ git checkout one.one
$ git submodule
asdfgh...456d subby (v1.1)

ただし、プル後、実行すると追加のサブモジュールが追加されます git submodule:

$ git pull . master
Auto-merged schema
CONFLICT (submodule): Merge conflict in subby - needs qu3rty...321e
Automatic merge failed; fix conflicts and then commit the results.

$ git submodule
qw3rty...321e subby (v1.0)
asdfgh...456d subby (v1.1)
zxcvbn...7890 subby (v1.1~1)

不要なサブモジュール参照を削除/無視して、競合や変更をコミットするにはどうすればよいですか?それともオリジナルで使用できるパラメータはありますか git pull それは私のサブモジュールを無視しますか?

役に立ちましたか?

解決

その正確なエラーは以前見たことがありません。しかし、私はあなたが直面しているトラブルについて推測しています。 supery master および one.one ブランチには、 subby サブモジュールの異なる参照が含まれているため、 master からの変更をマージする場合、gitは v1.0 または v1.1 のどちらの参照を保持し、 > one supery のブランチ。

その場合は、必要なrefを選択し、その変更をコミットして競合を解決する必要があります。これは、まさに reset コマンドで行っていることです。

これは、プロジェクトのさまざまなブランチにあるサブモジュールのさまざまなバージョンを追跡する際の注意が必要な側面です。ただし、サブモジュールrefは、プロジェクトの他のコンポーネントとまったく同じです。 2つの異なるブランチが連続したマージ後に同じそれぞれのサブモジュールrefを追跡し続ける場合、gitは将来のマージでマージの競合を引き起こすことなくパターンを解決できるはずです。一方、サブモジュールrefを頻繁に切り替える場合は、多くの競合の解決に耐えなければならない場合があります。

他のヒント

まあ、それはサブモジュールとの競合を技術的に管理していません(つまり、これを維持しますが、そうではありません)が、作業を続ける方法を見つけました...そして、私がしなければならなかったのは、私の git status を出力し、サブモジュールをリセットします:

git reset HEAD subby
git commit

それはサブモジュールをプル前コミットにリセットします。この場合、まさに私が望んだものです。また、サブモジュールに変更を適用する必要がある他のケースでは、標準のサブモジュールワークフロー(チェックアウトマスター、目的のタグのプルダウンなど)でそれらを処理します。

この質問の答えに少し苦労しましたが、次の質問の答えはうまくいきませんでした。 同様のSO投稿 どちらか。これが私にとってうまくいったことです - 私の場合、サブモジュールは別のチームによって保守されていたため、マスターと私が取り組んでいたプロジェクトのローカルブランチの異なるサブモジュールバージョンから競合が発生したことに留意してください。

  1. 走る git status - 競合のあるサブモジュールフォルダーをメモします。
  2. サブモジュールを現在のブランチで最後にコミットされたバージョンにリセットします。

    git reset HEAD path/to/submodule

  3. この時点で、競合のないバージョンのサブモジュールが完成しました。これをサブモジュールのリポジトリで最新バージョンに更新できます。

    cd path/to/submodule
    git submodule foreach git pull origin SUBMODULE-BRANCH-NAME
  4. そして今、できるのは commit それから仕事に戻りましょう。

まず、参照するサブモジュールに必要なハッシュを見つけます。実行

~/supery/subby $ git co hashpointerhere
~/supery/subby $ cd ../
~/supery $ git add subby
~/supery $ git commit -m 'updated subby reference'

これは、サブモジュールを正しいハッシュ参照に取得し、それ以上競合することなく作業を続行するために機能しました。

ブランチへの git rebase -i origin / master でこの問題が発生しました。サブモジュールrefのマスターバージョンを取得したかったので、次のようにしました。

git reset master path / to / submodule

そして

git rebase --continue

これで問題は解決しました。

この議論から助けてください。 私の場合、

git reset HEAD subby
git commit

私のために働いた:)

まあ私の親ディレクトリで私は見る:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Unmerged paths:
(use "git reset HEAD <file>..." to unstage)
(use "git add <file>..." to mark resolution)

だから私はこれをやった

git reset HEAD linux
ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top