Wie verwalte ich Konflikte mit git Submodule?

Question

Ich habe ein git Superproject, die mehrere Submodule verweist und ich versuche, einen Workflow für den Rest der meine Projektmitglieder zu sperren innen heraus zu arbeiten.

Bei dieser Frage kann sagen, mein Superproject supery genannt wird und das Submodul ist subby genannt. (Dann ist eine Vereinfachung, was ich versuche zu tun ... Ich bin nicht wirklich die Zweige für Versionen, aber ich dachte, es wäre am einfachsten als eine Frage zu legen.)

Mein Hauptzweig supery hat den Tag v1.0 des git Projekt subby als Submodul verwiesen. Der Zweig des supery genannt one.one und veränderte die Referenz des Submodul mit dem Tag v1.1 von subby zu zeigen.

Ich kann ohne Probleme in jedem dieser Zweige arbeiten, aber wenn ich versuche, die one.one Zweig mit Änderungen aus dem master Zweig zu aktualisieren erhalte ich einige Konflikte und ich weiß nicht, wie sie zu lösen.

Im Grunde nach einem git pull . master während im subby Zweig läuft, es sieht aus wie es zusätzliche Submodule erstellt.

Bevor der Zug / fusionieren, bekomme ich die gewünschte Antwort von git submodule aus dem one.one Zweig:

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

Aber nach dem Zuge, fügt sie zusätzliche Submodule, wenn ich git submodule laufen:

$ 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)

Wie kann ich löschen / ignorieren die unerwünschten Submodul Referenzen und meine Konflikte und Änderungen zu übernehmen? Oder gibt es einen Parameter ich mit meiner ursprünglichen git pull verwenden kann, die meine Submodule ignorieren?

Answer 1

Ich habe nicht den genauen Fehler gesehen. Aber ich habe eine Vermutung über die Mühe, die Sie stoßen. Es sieht aus wie, weil die master und one.one Zweige supery verschiedene Refs für die subby Submodul enthalten, wenn Sie Änderungen von master git fusionieren nicht wissen, welche ref - v1.0 oder v1.1 -. Gehalten und durch den one.one Zweig des supery verfolgt werden sollte

Wenn das der Fall ist, dann müssen Sie die ref wählen, die Sie möchten und sich verpflichten, dass der Wandel, den Konflikt zu lösen. Das ist genau das, was Sie mit der tun zurückgesetzt Befehl.

Dies ist ein schwieriger Aspekt verschiedene Versionen eines Submodul in verschiedenen Zweigen des Projektes der Verfolgung. Aber das Submodul ref ist wie jede andere Komponente des Projekts. Wenn die beide verschiedenen Zweige weiter nach aufeinanderfolgenden verschmilzt die gleiche jeweilige Submodul Refs verfolgen, dann sollte git der Lage sein, um das Muster zu arbeiten, ohne in Zukunft verschmilzt verschmelzen Konflikte zu erhöhen. Auf der anderen Seite Sie, wenn der Schalter Submodul Refs häufig können Sie oben zu setzen mit viel Konfliktlösung.

Answer 2

Nun, es ist nicht technisch Verwaltung Konflikte mit Submodule (dh halten dies aber nicht, dass), aber ich habe einen Weg gefunden, weiter zu arbeiten ... und alles, was ich tun musste, war achten Sie auf meinen git status Ausgang und setzen Sie die Submodule :

git reset HEAD subby
git commit

Das würde das Modul in der Reset vorge ziehen begehen. Was in diesem Fall ist genau das, was ich wollte. Und in anderen Fällen, in denen ich die Änderungen an das Submodul angewandt benötigen, werde ich die mit dem Standard-Submodul Workflows Griff (checkout master, öffnen Sie den gewünschten Tag, usw.).

Answer 3

Ich kämpfte in dieser Frage ein wenig mit den Antworten und nicht viel Glück mit den Antworten in eine ähnliche SO schreiben entweder. So ist das, was für mich gearbeitet - wenn man bedenkt, dass in meinem Fall das Submodul von einem anderen Team gehalten wurde, so dass der Konflikt kam aus verschiedenen Submodul Versionen in Master und meinem lokalen Zweig des Projektes Ich arbeite an:

1. Ausführen git status - notieren Sie den Submodul Ordner mit Konflikten machen

2. Setzen Sie das Modul in die Version, die zuletzt engagiert im aktuellen Zweig war:

   git reset HEAD path/to/submodule

3. An diesem Punkt haben Sie eine konfliktfreie Version Ihres Submoduls, die Sie jetzt auf die neueste Version im Submodul Repository aktualisieren können:

   cd path/to/submodule
   git submodule foreach git pull origin SUBMODULE-BRANCH-NAME

4. Und jetzt können Sie commit dass und wieder an die Arbeit.

Answer 4

Suchen Sie zunächst den Hash Sie Ihren Submodul verweisen möchten. dann läuft

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

, die gearbeitet hat, für mich, mein Submodul auf die richtige Hashreferenz zu erhalten und weiter mit meiner Arbeit ohne weitere Konflikte zu bekommen.

Answer 5

Ich hatte dieses Problem mit git rebase -i origin/master auf einen Zweig. Ich wollte Master-Version des Submodul ref nehmen, so dass ich einfach tat:

git reset master path/to/submodule

und dann

git rebase --continue

, dass das Problem für mich gelöst.

Answer 6

Got Hilfe dieser Diskussion. In meinem Fall des

git reset HEAD subby
git commit

arbeitet für mich:)

Answer 7

Nun In meinem Elternverzeichnis sehe ich:

$ 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)

Also habe ich dies nur tat

git reset HEAD linux