Continuo dalla discussione iniziata qui: http://www.guitex.org/home/it/forum/10-corsi-e-didattica/91226-nuova-versione-della-guidaguit
Dork” post=91333sto cercando di capire (ad esempio la differenza tra revert e roll back
Non uso l’interfaccia grafica di GitHub perché non è disponibile per GNU/Linux (e comunque temo sia troppo strettamente legata a quel sito), però su Stack Overflow ho trovato questa domanda che dovrebbe risolvere il tuo quesito:
http://stackoverflow.com/questions/15039271/what-is-the-meaning-of-revert-this-commit-and-roll-back-this-commit-in-github-fo
Se ho capito bene, l’operazione di “revert” corrisponde al comando [tt]git revert[/tt], che genera un nuovo commit che annulla il commit indicato (lasciando quindi la cronologia precedente invariata); l’operazione di “roll back” dovrebbe eliminare il commit indicato dalla cronologia però il file rimane invariato, in modo da poter correggere il commit. Questo è quello che capisco dalla risposta.
Dork” post=91333oppure come fare da li, se possibile, il ripristino di solo una parte di un commit (che nella guida è l’andare a ciliegie “cherry-pick”) altra cosa che comunque, grazie alla guida e alla riga di comando non sarà un problema)
Un attimo, un attimo, potrebbe esserci un’incomprensione: il “cerry-picking” consiste nel prendere un singolo commit da un altro ramo (comodo se non devi fondere l’intero ramo ma solo integrare singole modifiche), non un commit parziale. È chiaro o va spiegato meglio?
Dork” post=91334Ok, mi sono risposto, ho fatto il fork, ho clonato il tutto in una cartella locale (che ha creato il sistema scaricandone all’interno tutto il contenuto remoto e attivando automaticamente il repo locale) ora da quello che ho capito, senza rischiare di fare danni (che comunque..anche se facessi..sarebbero “annullabili” tornando a una versione precedente) posso apportare le modifiche che ritengo opportune o utili e poi salvarle, farne il commit (in locale) e fare il push sul GuITeX. In questo modo io comunque non modifico il file originale ultima versione (come farei invece se facessi la stessa cosa su un mio repo on-line) ma viene segnalata la modifica che deve essere approvata e integrata con un merge dal responsabile del progetto. Giusto?
Non sono sicuro di aver ben compreso la domanda: tu in locale fai tutte le modifiche che vuoi (tranne riscrivere la cronologia precedente alle tue modifiche), poi aggiorni il repository remoto con [tt]git push[/tt]. Questo doppio passaggio (commit e push) può sembrare una duplicazione del lavoro, ma in realtà è molto comodo perché permette di avere repository solo locali (io per anni ho avuto un paio di repository solo in locale) o di lavorare in locale prima di inviare un bel pacchetto di modifiche in remoto (non è obbligatorio eseguire il push dopo ciascun commit), mentre nei vecchi VCS centralizzati un commit inviava la modifica anche in remoto. Ora, quello che si deve fare per integrare le proprie modifiche nel progetto che si è forkato dipende dal sito. Su GitHub devi fare una richiesta di pull, cosa che però non mi sembra tu abbia ancora fatto (se credevi di averlo già fatto) 😉 Ho risposto alla tua domanda o mi è sfuggito qualcosa?