In git le modifche rrivano per 'commit' cioè per gruppi (si spera) organizzati di variazioni su diversi files dello stesso branch. Il controllo di versione e le tecniche di aggiornamneto tra branch diversi si basano sul commit.
Puoi assgnare 'tag' e 'release id' ad un commit, così da poter tenere diversa granularità, o semplicemente non assgnare nessunparticolar esignificato al commit id, tranne quello di uno stato di avanzamento intermedio (utile se si sviluppa in gruppo).
A dx in alto del repository di mansr in gitHub vedi: Latest commit d3d6026 11 days ago
A sxmansr Add read support for WSD file format
Se prendi il mio che è fermo a quando abbiamo fatto le nostre prove, vedi:
Latest commit 1d5eab9 15 days ago
marco Version with simple pathc for DSD_MAX_SIZE and msvc14 solution.
Ma, ancora più importante, alla riga sopra leggi:
This branch is 22 commits ahead, 21 commits behind mansr:master.
Il che significa che da quando ho eseguito la fork, ho prodotto 22 commit e mansr 21.
Questa è una situazione che si è prodotta perchè noi abbiamo 'sviluppato' e prodotto patch inviate a mnnsr, che le ha ignorate e proceduto per la sua strada, quindi con ogni probabilità non è più possibile un merge fast fordward delle due branch (cioè un riallineamneto automatico della mia fork allo stato attuale di mansr, mantenendo le mie modifiche), ma se avessi fatto un riallineamento continuo, o avessi lavorato su branch separati, adesso ci troveremmo in una situazione meno complicata, dove probabilmente ci troveremmo ad essere solo indietro di qualche commit.
La storia la vedi qui:
https://github.com/mansr/sox/compare...coc1712:master.
Quanto sopra solo perchè dimostra bene il meccanismo dei commit.
Dimenticandoci del mio repository (che cancellerò) e facendo riferimento solo a quello di manr, registrarsi il commit dl quale hai prodotto gli eseguibili serve per poter verificare cosa è cambiato nel frattempo (click sull'orologino in altro a sx: xxx commits).
https://github.com/mansr/sox/commits/master.
Per ogni commit puoi vedere il codice modificato ed eventualmente produrre una patch.
Quello che farei io, sarebbe mantenere una fork in sola lettura (o un clone) del repo di mansr, da cui produrre gli eseguibili, quindi - ogni volta che volessi aggiornarli, prima farei una merge fast forward, così da riallinearmi, quindi compilerei. In questo modo avresti sempre una copia dei sorgenti effettivamente sottostanti agli eseguibili.
Non è obbligatorio che questo repo sia in gitHUb, puoi anche tenerlo locale, ma se lo pubblichi assolvi pienamente agli obblighi e non ti curi di dover mandare i sorgenti a chi li richiede, in alternativa, pubblicando il commit cui eri allineato quando hai prodotto gli eseguibili, assolvi egualmente agli obblighi, ma rendi la vita un po più difficile a chi legge.
Spero di essere stato chiaro, altrimenti chiedi.
Rispondi quotando