Come gestisco i conflitti con i sottomoduli git?

Ho un superprogetto git che fa riferimento a diversi sottomoduli e sto provando a bloccare un flusso di lavoro affinché gli altri membri del mio progetto lavorino all'interno.

Per questa domanda, supponiamo che il mio superprogetto venga chiamato superye venga chiamato il sottomodulo 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 superyha il tag v1.0del progetto git subbyindicato come sottomodulo. Il ramo di superychiamato one.onee modificato il riferimento del sottomodulo in modo che punti al tag v1.1di subby.

Posso lavorare all'interno di ciascuno di questi rami senza intoppi, ma se provo ad aggiornare il one.oneramo con le modifiche dal masterramo ricevo alcuni conflitti e non riesco a risolverli.

Fondamentalmente dopo aver eseguito un git pull . masterpo 'di tempo nel subbyramo, sembra che crei sottomoduli aggiuntivi.

Prima del pull / merge, ottengo la risposta desiderata git submoduledal one.oneramo:

$ 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 corro 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 posso eliminare / ignorare i riferimenti al sottomodulo indesiderati e impegnare i miei conflitti e le mie modifiche? O c'è un parametro che posso usare con il mio originale git pullche ignorerà i miei sottomoduli?

Non ho mai visto quell'errore esatto prima. Ma ho un'idea del problema che stai riscontrando. Sembra che i rami mastere one.onedi superycontengano riferimenti diversi per il subbysottomodulo, quando unisci le modifiche a mastergit non sa quale ref - v1.0o v1.1- dovrebbe essere tenuto e tracciato dal one.oneramo di supery.

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

Questo è un aspetto complicato 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 tenere traccia degli 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.

Bene, 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 statusoutput e ripristinare 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.).

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 a cui stavo lavorando:

1. Esegui git status: annota la cartella del sottomodulo con conflitti

2. Reimpostare il sottomodulo sulla versione che è stata salvata 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:

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

4. E ora puoi commitfarlo e tornare al lavoro.

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

~/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.

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

git reset master path/to/submodule

e poi

git rebase --continue

Ciò ha risolto il problema per me.

Ho ricevuto aiuto da questa discussione. Nel mio caso il

git reset HEAD subby
git commit

ha funzionato per me :)

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