Il git checkout documentation dice:git checkout: significato dettagliato di "loro" e "nostro"
--ours --theirs Al check-out percorsi dall'indice, controlla palco # 2 (nostro) o # 3 (loro) per percorsi non raggruppati.
Qual è il significato di "stage # 2" e "stage # 3" durante l'unione, il rebase e il cherry-pick? C'è un modo per interrogare questi "stadi" prima di eseguire il comando per assicurarsi che recupererà la versione corretta?
Questi sono documentati (anche se non tutto quello che chiaramente, credo) in the gitrevisions documentation:
Un colon, eventualmente seguito da un numero di fase (0-3) e due punti, seguito da un percorso, nomi un oggetto blob nell'indice nel percorso specificato. Un numero di stage mancante (e i due punti che lo seguono) indicano una voce dello stage 0. Durante l'unione, lo stadio 1 è l'antenato comune, lo stage 2 è la versione del ramo di destinazione (in genere il ramo corrente) e lo stadio 3 è la versione del ramo che viene unito.
A questi, è quindi necessario aggiungere la conoscenza di come funzionano git rebase e git cherry-pick.
La normale selezione della ciliegia è ben definita: "la nostra" è la versione HEAD, ovvero il ramo in cui eri (e lo è ancora), mentre "loro" è il commit che stai attivamente selezionando. Quando selezioni un singolo commit, è abbastanza ovvio: la fase n. 1 è l'antenato comune, la fase n. 2 è la versione dalla punta del tuo ramo attuale, e la fase n. 3 è la versione che stai selezionando.
Se si seleziona una serie di commit, questo è ancora vero, è vero solo iterativamente. Supponiamo che tu scelga tre commit, ad esempio. Git semplicemente fa i tre uno alla volta. Durante il primo cherry-pick, lo stage # 2 è la punta del tuo branch, e il punto 3 è la versione dal primo commit che viene selezionata con la ciliegia. Una volta che il commit di cherry-pick finisce, git fa un nuovo commit, avanzando la punta del tuo ramo. Quindi, durante il secondo cherry-pick, lo stage # 2 è la punta del tuo ramo, che è il commit del tuo primo cherry-pick, e il punto 3 è la versione del secondo commit selezionato. Questo si ripete di nuovo per il commit finale. Ogni volta, la fase # 3 è la "loro" versione.
Rebase, tuttavia, è un po 'complicato. Internamente, inizia mettendoti su una nuova filiale anonima (un "TESTO distaccato"). Quindi viene eseguito git cherry-pick per prelevare ogni commit dal ramo originale. Ciò significa che "nostro" è la versione distaccata HEAD, mentre "theirs" è la versione del tuo ramo originale. Proprio come cherry-pick, questo si ripete in modo iterativo per ogni commit da selezionare (letteralmente nel caso di un rebase interattivo, in cui si modificano le linee pick). Una volta terminato il rebase, git rimescola semplicemente l'etichetta del ramo in modo che il nuovo ramo anonimo appena creato sia il tuo codice.
In breve, si può pensare a rebase come "invertire le impostazioni nostre/loro", ma questa è un'esagerazione. Potrebbe essere più preciso dire che la fase 2 è il tuo nuovo codice combinato e lo stadio 3 è il tuo vecchio codice.
I Git documentation for merge (così come pochi altri posti) spiega che un file indice record fino a tre versioni, o stadi:
Per i percorsi conflittuali, i record di file di indice fino a tre versioni: fase 1 memorizza la versione dall'antenato comune, fase 2 da HEAD e fase 3 da MERGE_HEAD (puoi controllare le fasi con git ls-files -u). I file dell'albero di lavoro contengono il risultato del programma "unione"; vale a dire i risultati dell'unione a 3 vie con indicatori di conflitto noti < < < === >>>.
Qui è un diagramma che mostra quanto i tre stadi sono in un tipico unione Git:
Common Ancestor -> C1 --- C2 <- MERGE_HEAD (Stage 3)
(Stage 1) \
--- C3 --- C4 <- HEAD (Stage 2)
Ciò presuppone che il ramo cui HEAD è C4 viene unita indietro sul ramo termina in C2.
Come afferma documentazione, si può effettivamente vedere le fasi digitando:
git ls-files -u