Qualcuno va d'accordo con Git e GitHub?

[Sjuanez]

Salve a tutti.

Da un po di tempo uso Git e GitHub ma per repository personali, quindi non ho mai provato più di tanto la condivisione e sopratutto la sincronizzazione delle repo mentre ci lavora anche qualche altra persona.

Ora sto cercando di rendermi utile al progetto FidoCadJ che chiaramente tutti conoscete e con il buon DarwinNE non riusciamo a risolvere una questioncina. Nello specifico si tratta della branch del sito di FidoCadJ.

Come potete immaginare ci sono 4 repository in gioco:
quella ufficiale che è sull'account GitHub di DarwinNE
quella su cui lavora lui personalmente, che si trova sul suo PC
la mia fork sul mio account GitHub
la mia fork sul mio computer

Dunque i passaggi che seguiamo sono quelli canonici.
io apporto una modifica al codice sul mio PC
faccio una commit della modifica sul mio PC
sincronizzo la mia repository con quella del mio account GitHub
faccio una pull request dal mio account GitHub alla repo ufficiale di DarwinNE
lui la accetta e la rende ufficiale

Ora, ed è questo il bello: se voglio dedicarmi a qualche altro lavoretto e faccio un compare tra la mia repo e la sua mi dice che non sono sincronizzate. E indovinate cosa mi propone di fare?

Di accettare la commit che io avevo inviato a lui e lui aveva accettato, come nuova modifica. Se lo faccio e sistemo manualmente conflitti che non dovrebbero esserci, maledetto a lui, mi propone di inviarla a DarwinNE come pull request!

Prima di andare ancora più nel dettaglio, fatemi sapere voi se vi sembra che stiamo sbagliando qualcosa. Più probabile che sia io in errore, Davide sa il fatto suo.

Resto a disposizione per ulteriori chiarimenti. La mia prossima soluzione, per continuare a lavorare al progetto, è sforkettarlo e riforkettarlo di nuovo.

Mi permetto di invocare l'utente angus che più volte ha mostrato di essere assai competente in informatica.

Saluti a tutti e grazie.

[DarwinNE]

Stavamo appunto discutendo con Sjuanez, sembra che qualcosa non ci risulti molto chiaro, in effetti. Io non sono un grande esperto di Git, sto imparando ad usarlo un po' alla volta.
Dopo che ho dovuto fare un merge manuale, riporto qui un mio messaggio, in cui cerco di capire come stanno le cose. Il messaggio riassume più o meno quello che ho capito di Git fino ad adesso

Se qualcuno potesse dirci come muoverci, darebbe un ottimo contributo a FidoCadJ

Ciao,
ci sono cose che non capisco molto bene neppure io.

Ho seguito più o meno le istruzioni datemi da GitHub per fare il merge manualmente. Se guardi questa pagina:

https://github.com/DarwinNE/FidoCadJ/network

però non si vede la freccina che indica che la PR che hai fatto ieri è stata inclusa in gh-pages (eppure una volta ha funzionato).

Quindi, penso che il codice sia stato integrato, ma GitHub non considera che le due branch siano state allineate. In effetti, stiamo lavorando su quattro repository distinti:

1 - il repository mio locale sul mio computer
2 - il repository mio remoto su GitHub https://github.com/DarwinNE/FidoCadJ.git
3 - il repository tuo locale sul tuo computer
4 - il repository tuo remoto su GitHub https://github.com/MigthyThor/FidoCadJ.git

Quando tu fai un git branch -a, lui ti mostra tutte le branch che hai attive sul tuo repository locale. Per esempio, adesso io ho:

Codice: Seleziona tutto

[davidebucci@davide-bucci-portable-2]$ git branch -a
* gh-pages
  master
  remotes/origin/HEAD -> origin/master
  remotes/origin/gh-pages
  remotes/origin/master
[davidebucci@davide-bucci-portable-2]$


sto lavorando in locale su gh-pages e quindi git mi aggiunge un asterisco a sinistra.
Se ho capito bene, bisogna pensare a remotes/origin/eccetera come delle branch un po' speciali, che di fatto sono dei link al repository su GitHub:

https://git-scm.com/book/it/v2/Git-Bran ... e-Branches

Quindi, per te remotes/origin/gh-pages punterà alla branch gh-pages del repository https://github.com/MigthyThor/FidoCadJ.git e per me alla branch gh-pages del repository https://github.com/DarwinNE/FidoCadJ.git

Quando fai i tuoi bravi push o pull, in pratica allinei la tua branch locale con quella distante su GitHub. E non con la mia, il che spiega perché il tuo codice non è aggiornato.

Secondo me e se ci ho capito qualcosa, tu dovresti provare a fare quanto segue:

1 - Crearti intanto una nuova branch in locale per fare qualche prova liberamente, per esempio DarwinNE_gh-pages con

Codice: Seleziona tutto

git checkout -b DarwinNE-gh-pages


nonappena creata, questa branch sarà allineata alla tua branch gh-pages, perché finora hai lavorato solo in locale e non ti sei collegato a nessun server.

2 - Fai un pull della mia branch gh-pages su GitHub:

Codice: Seleziona tutto

git pull https://github.com/DarwinNE/FidoCadJ.git gh-pages

Il pull funziona così: Git dapprima si collega al server (GitHub), legge il mio repository, cerca la branch gh-pages e si salva tutti i dati tenendoseli da parte (operazione "fetch"). Poi cerca di mischiare insieme i file se ce la fa (operazione merge).
Nel nostro caso, ci saranno dei conflitti, perché il codice mio è diverso dal tuo.
Puoi trovare i conflitti facilmente nei file aprendoli e cercando le linee tipo queste:

Codice: Seleziona tutto

<<<<<<< HEAD
         <p><b>Warning</b>: we are progressively migrating all the FidoCadJ project from SourceForge to GitHub; some links in this website still point to SourceForge pages.</p>
=======

>>>>>>> 292813038851cf37e73642c27285e280ffc6226c

(risulta da un conflitto che ho risolto, in cui nella mia versione c'è una frase che ho aggiunto e che nel tuo commit manca).

3 - Forzi Git a scegliere la mia versione dei file. Ora, vedi le cose dal tuo punto di vista ed immagina di avere un amico immaginario che ti guarda mentre scrivi. Quindi "noi" dal tuo punto di vista siete tu ed il tuo amico immaginario. "Loro" siamo io e Robert che è qui a controllare quello che scrivo io. Se quindi vuoi dirgli di prendere i file miei devi dire "theirs" nel gergo Git:

Codice: Seleziona tutto

git checkout --theirs download.html

da ripetere per tutti i file per cui ti segnala i conflitti.

4 - Il resto lo immagini: ora nella branch DarwinNE-gh-pages hai una versione che (si spera) dovrebbe essere allineata alla mia. Puoi fare git add e git commit.

In realtà, non sei neanche obbligato a crearti la branch DarwinNE-gh-pages ogni volta, qui serve per fare qualche prova. Infatti, puoi fare git pull direttamente dalla tua gh-pages. Puoi fare un git diff per vederti le differenze fra le due branch.
Però usa il comando con il riferimento al server visto al punto 3 e non un semplice "git pull", altrimenti ti ritrovi con il link che puntano al tuo repository remoto e non al mio.

Fammi sapere, puoi provare finché vuoi e ritornare all'ultimo tuo commit con

Codice: Seleziona tutto

git reset --hard

ed eliminare una branch con:

Codice: Seleziona tutto

git branch -d nome_branch_da_eliminare

Boh, non proprio facilissimo, ma credo che una volta digerita la filosofia non sia poi una cosa così terribile.

Fai una cosa, salva questa risposta da qualche parte, casomai ci servisse da aggiungere nelle Wiki, temo sarà un argomento ricorrente.

Se ho cannato qualcosa (è da poco che uso Git), fammi sapere che cerchiamo poi di correggere.

Cheers,

D.

Ovviamente, ci sono dei conflitti fra il repo mio e quello di Sjuanez, perché anch'io ho fatto commit di modifiche nella branch gh-pages su cui lavora anche lui e queste modifiche non sono state finora integrate nel repository di Sjuanez.

[angus]

Al momento sono estremamente di corsa...
Se non lo avete già visto, vi lascio un link che per me è stato illuminante...
http://nvie.com/posts/a-successful-git-branching-model/

[Sjuanez]

Intanto grazie mille per essere passato. Me lo guarderò con calma!

[IlGuru]

Anche io sono verginello di github, quindi potrei dire una stupidata.
Una volta che una modifica è stata integrata nel repo master su github, anche se c'è un fork solo da cui provengono le modifiche integrate, non è che questo fork su github debba essere comunque sincronizzato con il master?
E' vero che il contenuto è identico, ma i vari id che identificano la versione ecc no.
Dopodichè anche DarwinNE dovrà sincronizzare il suo repo locale con quello master, e tu con il tuo fork su github.
Penso che a github non freghi molto che ci sia un fork solo o n, tratta tuto in generale come dipendente sempre dal master.
Mi scuso se ho detto boiate.

[Sjuanez]

IlGuru il concetto di master è meglio stare attenti a non confonderlo con la master branch. Cerco di fare chiarezza come meglio mi riesce, ma già sapete che sto imparando come voi.

Appurato che non esiste una Repo centrale, il fatto di considerare quella di DarwinNE come "principale" o "ufficiale" è una cosa che resta tra noi. Per quanto ne frega a Git, da domani la mia Fork potrebbe divenire il nuovo FidoCadJ. Sono quindi versioni decentralizzate e apparentemente indipendenti.

Io faccio un cambiamento sintetizzato da un Hash SHA-1 (una stringa di valori esadecimali derivante da un algoritmo di Git) serve a sintetizzare i miei cambiamenti. (si legge se fate un "git log").

Se ho capito bene, la mia repo e quella di DarwinNE non saranno mai formalmente identiche per il semplice fatto che io faccio dei cambiamenti e lui li riceve (e viceversa). Quindi possiamo continuare a scambiarci "change set" o commit, ma dovremmo ottenere Hash SHA-1 diversi.

Uno dei nostri guai è derivato dal fatto che, essendo stato costretto DarwinNE a modificare manualmente una mia commit per farla stare nella sua repository, ha generato un "change set" sostanzialmente identico al mio, ma formalmente diverso.

Rimanete sintonizzati che questa storia la sistemeremo!

Grazie IlGuru di essere passato!

[DarwinNE]

Sono quindi versioni decentralizzate e apparentemente indipendenti.

Esatto! Bisogna fare attenzione perché quando uno viene da Subversion rischia di fare confusione appunto su quello.

Se ho capito bene il problema è che Sjuanez non riesce ad importare le modifiche che faccio io.
Quindi io riesco ad accettare le sue pull request, ma poi se rivedo il codice poi lui non riesce ad ottenere le mie modifiche ed alle successive pull request che mi manda il sistema (giustamente) si lamenta che ci sono dei conflitti.

[Sjuanez]

ci sono dei conflitti.

Ancora per poco

[IlGuru]

Ioho inviato due pull request al repo di kicad, se me le accettano vi sapròdire se avrò problemi a sincronizzare o no. Prima volta che uso github con altri.

[webmaster]

Se ho capito bene il problema è che Sjuanez non riesce ad importare le modifiche che faccio io.
Quindi io riesco ad accettare le sue pull request, ma poi se rivedo il codice poi lui non riesce ad ottenere le mie modifiche ed alle successive pull request che mi manda il sistema (giustamente) si lamenta che ci sono dei conflitti.

Uso git quotidianamente da vari anni, quindi posso provare ad aiutarvi... Devo prima pero` capire esattamente qual e` il problema e qual e` l'esatto flusso per riprodurlo.
DarwinNE, cosa intendi quando dici che Sjuanez non riesce ad ottenere le tue modifiche dopo il merge?

In generale, per capire bene git, ci sono dei punti fondamentali da assimilare:

• Ogni commit e` collegato ad uno snapshot del repository, e lo snapshot descrive completamente il contenuto del repository per quel commit
• Ogni commit puo` avere uno o piu` predecessori. Uno per un commit semplice, due o piu` nel caso di un merge.
• Una branch e` semplicemente un puntatore ad un determinato commit. Ad un nuovo commit, il puntatore della branch corrente viene fatto puntare al nuovo commit. Nel caso di un merge, i predecessori sono solitamente due: quello del commit del branch corrente e quello del commit della branch da cui si sta mergiando
• Se il commit del branch A e` un predecessore del commit del branch B, allora mergiando B in A non si creeranno nuovi commit, ma semplicemente il puntatore di A verra` fatto puntare al commit di B. Questo tipo di merge viene chiamato fast forward

In generale, dopo che DarwinNE accetta la pull request, non e` detto che il repository di Sjuanez sia in sync. Lo sara` solo se il merge e` stato un fast-forward.

Alcuni progetti open source accettano solo fast-forward, in quanto con un fast-forward non ci sono conflitti da risolvere. Per fare in modo che un merge di B in A sia un fast-forward, di solito si fa un merge di A in B prima del merge di B in A. Se poi si vuole una history dei commit piu` pulita, senza biforcazioni, si mergia A in B con un rebase, che replica le modifiche di B su A creando nuovi commit e mantenendo cosi` l'history lineare...

Agli inizi e` un po' complicato, ma con un po' di pratica diventa naturale, e la genialita` del sistema diventa evidente!

Il libro ufficiale di git e` completamente disponibile al sito https://git-scm.com/doc. Lo consiglio vivamente, e` molto chiaro contiene anche svariati diagrammi che aiutano a capirne i meccanismi.