Come gestisco i conflitti con i sottomoduli git?

Question

Ho un superprogetto git che fa riferimento a diversi sottomoduli e sto provando a bloccare un flusso di lavoro per far funzionare il resto dei membri del mio progetto.

Per questa domanda, diciamo che il mio superprogetto si chiama supery e il sottomodulo si chiama subby . (Quindi è una semplificazione di ciò che sto cercando di fare ... In realtà non sto usando i rami per le versioni, ma ho pensato che sarebbe stato più semplice fare una domanda.)

Il mio ramo principale di supery ha il tag v1.0 del progetto git subby indicato come sottomodulo. Il ramo di supery chiamato one.one e ha cambiato il riferimento del sottomodulo in modo che punti al tag v1.1 di subby .

Posso lavorare all'interno di ciascuno di questi rami senza intoppi, ma se provo ad aggiornare il ramo one.one con le modifiche dal ramo master ricevo alcuni conflitti e non so come risolverli.

Fondamentalmente dopo aver eseguito un git pull. master mentre si trova nel ramo subby , sembra che crei sottomoduli aggiuntivi.

Prima del pull / merge, ottengo la risposta desiderata da git submodule dal ramo one.one :

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

Ma dopo il pull, aggiunge ulteriori sottomoduli quando eseguo 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)

Come elimino / ignoro i riferimenti al sottomodulo indesiderati e commetto i miei conflitti e le mie modifiche? Oppure c'è un parametro che posso usare con il mio git pull originale che ignorerà i miei sottomoduli?

Answer 1

Non ho mai visto quell'errore esatto prima. Ma ho un'idea del problema che stai riscontrando. Sembra che i rami master e one.one di supery contengano riferimenti diversi per il sottomodulo subby , quando unisci le modifiche da master git non sa quale ref - v1.0 o v1.1 - deve essere tenuto e tracciato dal one.one ramo di supery .

In tal caso, è necessario selezionare il riferimento desiderato e confermare la modifica per risolvere il conflitto. Il che è esattamente quello che stai facendo con il comando reset .

Questo è un aspetto difficile del tracciamento di diverse versioni di un sottomodulo in diversi rami del progetto. Ma il riferimento al sottomodulo è proprio come qualsiasi altro componente del tuo progetto. Se i due diversi rami continuano a tracciare gli stessi rispettivi riferimenti del sottomodulo dopo successive fusioni, allora git dovrebbe essere in grado di elaborare il modello senza sollevare conflitti di fusione in future fusioni. D'altra parte, se si cambia frequentemente i riferimenti al sottomodulo, potrebbe essere necessario affrontare un sacco di risoluzione dei conflitti.

Answer 2

Beh, non è tecnicamente gestire i conflitti con i sottomoduli (cioè: mantieni questo ma non quello), ma ho trovato un modo per continuare a lavorare ... e tutto quello che dovevo fare era prestare attenzione al mio git status emette e reimposta i sottomoduli:

git reset HEAD subby
git commit

Ciò ripristinerebbe il sottomodulo al commit pre-pull. Che in questo caso è esattamente quello che volevo. E in altri casi in cui ho bisogno delle modifiche applicate al sottomodulo, gestirò quelle con i flussi di lavoro del sottomodulo standard (checkout master, abbassa il tag desiderato, ecc.)

Answer 3

Ho faticato un po 'con le risposte a questa domanda e non ho avuto molta fortuna con le risposte in un post SO simile . Quindi questo è ciò che ha funzionato per me, tenendo presente che nel mio caso, il sottomodulo è stato gestito da un team diverso, quindi il conflitto è venuto da diverse versioni di sottomodulo in master e il mio ramo locale del progetto su cui stavo lavorando:

1. Esegui git status - prendi nota della cartella del sottomodulo con conflitti

2. Ripristina il sottomodulo sulla versione che è stata salvata per l'ultima volta nel ramo corrente:

   git reset HEAD path / to / submodule

3. A questo punto, hai una versione senza conflitti del tuo sottomodulo che ora puoi aggiornare all'ultima versione nel repository del sottomodulo:

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

4. E ora puoi eseguire il commit e tornare al lavoro.

Answer 4

Per prima cosa, trova l'hash che vuoi fare riferimento al tuo sottomodulo. quindi esegui

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

che ha funzionato per me per ottenere il mio sottomodulo con il riferimento hash corretto e continuare con il mio lavoro senza ulteriori conflitti.

Answer 5

Ho avuto questo problema con git rebase -i origin / master su un ramo. Volevo prendere la versione principale del riferimento al sottomodulo, quindi ho semplicemente fatto:

git reset percorso principale / to / submodule

e poi

git rebase --continuue

Ciò ha risolto il problema per me.

Answer 6

Ho ricevuto aiuto da questa discussione. Nel mio caso il

git reset HEAD subby
git commit

ha funzionato per me :)

Answer 7

Bene Nella mia directory principale vedo:

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

Quindi l'ho appena fatto

git reset HEAD linux