Richiesta chiarimenti per sincronizzazione repo.

[Nefando]

Premetto che sto usando GitHub Desktop e non ho ancora utilizzato i comandi da riga. In tutta franchezza, se fosse possibile continuerei coì :)

Dopo il Merge della PR #23 ho provveduto a fare una (reverse) PR dal Neurone/dev al Nefando/dev.
Il repo è stato effettivamente aggiornato, sincronizzandolo con il dev attuale, però continua a segnalare che "This branch is 15 commits ahead of Neurone:dev". Andando a vedere, i 15 commit sono gli stessi che sono stati originariamente inviati con la PR (14 più quello di aggiornamento della versione nei file.mod e .json).
Fino a che i file vengono sincronizzati correttamente, questo non rappresenta un vero e proprio problema, però col tempo immagino che il numero di commit "fantasma" genererà confusione nella gestione del repo. E, forse, continueranno ad essere inseriti nelle future PR?
Vorrei capire cose e dove ho sbagliato e come è possibile ottenere un repo senza commit ridondanti. Alle brutte posso anche cancellare il repo e fare un clone nuovo (dopo il Merge della PR #24 magari...), ma voglio capire come evitare questa cosa in futuro.

[Neurone]

Ciao Nefando, il problema è tipico dei sistemi distribuiti e del modo di sviluppare con git: il trucco è non creare dei commit diversi sul tuo repo rispetto a quello degli altri (come ad esempio il commit di merge che hai creato per sincronizzarti) ma sincronizzarti usando una tecnica di aggiornamento diversa (pull + eventualmente rebase per le operazioni che intanto hai fatto in locale).

La stessa tecnica ti servirà per evitare ad esempio che un branch separato (tipo quello che hai per la traduzione di federations) faccia un mix strano di commit in avanti e indietro. Attualmente il branch traduzione-federations dice "This branch is 29 commits ahead, 14 commits behind Neurone:dev.", ma le 14 sono comprese in realtà nelle 29.

E' più lungo a spiegare che a farsi, e normalmente si risolve senza problemi con pochi comandi da shell, ma visto che ti trovi bene con GitHub Desktop provo a verificare se si può fare anche con quello. Dammi solo un po' di tempo per fare delle prove e ti dico, ma non garantisco per Microsoft :)

[Nefando]

Ok, grazie per l'aiuto.
Eventualmente, visto che sembra molto più conveniente che sia io a rassegnarmi, che comandi dovrei usare nel prompt per risolvere questo problema dei commit?

Invece per la sincronizzazione mi avevi segnalato questo: git pull upstream dev . Basta eseguire questo comando quando ci sono nuovi merge nel tuo dev o ci sono altre istruzioni da fare prima (o dopo)?
Quali differenti risultati ottengo invece usando git pull --no-commit <remote> o git pull --rebase <remote>? Cercando ho trovato questi comandi ma non sono sicuro di aver capito fino in fondo le differenze (a naso punterei su quest'ultimo, git pull --rebase <remote>).

Devi avere pazienza: immagina di parlarne ad uno che non ne sa niente :)

EDIT: Ho provato a cercare un metodo e alla fine ho provato così (sul mio branch dev):

1. Ho fatto un rebase interattivo dal tuo dev usando il comando git rebase -i upstream/dev.
2. Nella selezione dei commit ho fatto drop su tutte le linee.
3. Finito il rebase la copia in locale era mancante dei famosi 15 commit ridondanti, che invece erano ancora presenti su Github.com.
4. Ho eseguito il comando git push -f origin dev per forzare il "caricamento dell'assenza di commit" (espressione da poeta russo suicida, lo so, ma non mi viene un modo migliore per definirla).
5. Finalmente adesso vedo This branch is even with Neurone:dev.

Sperando di aver trovato una soluzione valida, ti chiedo comunque dettagliatamente quali comandi utilizzare in futuro per la sincronizzazione, per evitare a priori questa trafila.

[Neurone]

Gradissimo! :) Non ti preoccupare a chiedere qualunque cosa, siamo qui apposta per chiarire tutto quello che serve.

La procedura che hai seguito è corretta, anche se spesso non è necessario "uccidere" i commit o fare un rebase interattivo, ma riesce a fare git da solo spesso quasi tutto. E' sufficiente un semplice:

git rebase upstream dev

Il pull è sufficiente quando vuoi aggiornare il tuo repo rispetto a quello remoto, ma non hai modifiche diverse in locale rispetto al remoto (sei solo indietro).

Il "force" durante il push invece è spesso necessario perché il repo "origin" (il tuo repo github) rimane spesso indietro con gli aggiornamenti.

Procedura normale

Poiché è comune che mentre lavori su un branch (es. traduzione-federations) intanto il branch principale (dev) sul repo upstream (il mio github) vada avanti (perché accoglie ad esempio le modifiche degli altri sviluppatori), ogni volta che inizia a modificare qualcosa (es. a inizio giornata se la PR richiede più giorni) il flusso prevede che ogni svlippatore allinei sempre il proprio stato attuale, correggendo eventuali problemi che dovessero essere sorti nel mentre, per poi continuare con le modifiche.

In questo progetto specifico, gli unici problemi di conflitti che possono sorgere sono quando andiamo magari a modificare esattamente la stessa riga: in quel caso git non sa come comportarsi e serve un intervento manuale che il rebase automatico non riesce a risolvere. Ma poiché git lavora a singole linee di codice, è quasi sempre in grado di fare il rebase senza problemi dello stesso file modificato contemporaneamente da più persone, in tempi diversi.

Adesso puoi provare direttamente il tutto sulla attuale PR (magari fai un backup prima ^^), ed ho verificato che si può fare anche da GitHub Desktop se vuoi:

• Seleziona da GHD il branch "traduzione-federations", che attualmente risulta "This branch is 29 commits ahead, 14 commits behind Neurone:dev."
• Seleziona Branch->Rebase current branch...->upstream/dev->Start rebase
• Appare messaggio di warning "se fai rebase guarda che poi dovrai fare un push forzato"->Begin rebase. A questo punto il tuo repo locale è aggiornato
• In alto a destra appare a questo punto "Force push origin"->Messaggio di warning "sei sicuro?"->Sì :) A questo punto anche il repo origin (github) è aggiornato e di conseguenza la PR si aggiornerà e dovresti vedere solo un messaggio del tipo "This branch is xx commits ahead of Neurone:dev"

Se vuoi sperimentare senza usare questo repo, ho creato appena adesso un repo di prova se vuoi fare delle prove lì (https://github.com/Neurone/git-rocks) altrimenti ne puoi creare anche due tuoi e rendere uno upstream dell'altro.

Se nel mentre invece ti sei appassionato alla riga di comando e vuoi approfondire, uno dei migliori tutorial git per me è quello di Atlassian (https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow).

Fammi sapere per qualuque dubbio.

[Nefando]

Perfetto, ottima spiegazione, mi hai chiarito qualche dubbio.

Ho fatto il rebase (è andata liscia con GHD come mi hai illustrato) e adesso la PR e il branch traduzione_federations sono aggiornati con i 20 commit reali. Si può andare avanti con la revisione, nel mentre le traduzioni che dovessi aggiungere le metto in coda alla PR esistente.