Chiedo agli autori: per caso avete intenzione di trasferire il repository su GitHub?
Ho dato una lettura alla guida, alcuni paragrafi sono particolarmente scorrevoli, anche piacevoli da leggere. 😉 Comunque ho notato alcuni refusi e un paio di imprecisioni. Per il momento li segno qui, anche per discuterne (se volete potete integrarli voi, se li ritenete validi).
Innanzitutto, parlando di GUI io farei almeno una menzione a gitk o gitg.
Ma andiamo al sodo: paragrafo 3.4.1.
Se si vogliono riportare allo stato dell’ultimo commit registrato solo determinati file che sono modified ma non ancora staged, adottando la terminologia vista all’inizio, senza toccare la restante working directory si può utilizzare il comando
`$ git commit — < file >`
Immagino si intenda [tt]git checkout[/tt].
Poco dopo (infatti):
Il comando git checkout —
può anche essere usato per ripristinare file accidentalmente cancellati prima effettuare un nuovo commit. In questo caso l’uso del doppio trattino è necessario dal momento che il file cancellato non si trova nella working directory e Git non capirebbe che è con certezza un elenco di file cancellati.
Non mi risulta che [tt]–[/tt] sia necessario. Come al solito, è consigliato se si possono avere ambiguità, ma non mi pare sia obbligatorio. Ovviamente, dato che il file è stato cancellato, non è possibile usare TAB per completarne automaticamente il nome, ma non per questo non viene riconosciuto da git.
A seguire:
I file tolti dalla staging area possono poi anche essere ripristinati allo stato del commit precedente usando il comando git commit —
illustrato qui sopra.
Come sopra: [tt]git checkout[/tt]?
Paragrafo 3.4.2:
L’opzione –amend del comando git commit permette di modificare l’ultimo commit, ma a patto che non sia già stato inviato a un server remoto con git push. Questa apparente limitazione è dovuta al fatto che quando il server remoto riceve la nuova versione del repository non si aspetta che la cronologia dei commit che già conosce venga modificata e questa è una misura di sicurezza voluta dagli sviluppatori di Git che assicura che un repository non possa essere alterato da malintenzionati.
Sembra naturale pensare a una misura di sicurezza, ma in realtà non è così, o meglio: non in questo senso. Si può benissimo inviare al server remoto un commit modificato: basta usare [tt]git push -f[/tt]. Il motivo per cui va usato con attenzione è che altera la cronologia dei commit nel server remoto e può mandare in subbuglio i repositori degli altri sviluppatori (non mi è mai capitato ma leggendo in giro non sembra piacevole ;)). Se vogliamo trovare un motivo “di sicurezza”, è per costringere a fare il merge in locale, evitando che vada perso del lavoro. Per esempio se A e B partono dallo stesso commit, fanno ciascuno un commit nella propria copia di lavoro e poi A fa il push, se anche B potesse fare semplicemente il suo push, andrebbe eseguito un merge automatico in remoto …che git non prevede! 😉 Di conseguenza o si fa il merge locale o si perde il lavoro di A!
Un’altra cosa. Quando viene descritto [tt]git revert[/tt], dato che si cita HEAD, può essere il punto giusto per parlare delle notazioni [tt]^[/tt] e [tt]~N[/tt], che evitano di dover ricopiare l’hash certe volte. Infine, opinione personale, io lascerei stare [tt]inotifywait[/tt] che va completamente contro il senso di un sistema come git, in cui ogni commit dovrebbe avere uno specifico obiettivo.
Ciao,
Antonio